SAP Reinsurance Management For SAP S - 4HANA PDF

USER GUIDE | PUBLIC
Document Version: 3.0 – 2018-07-27
SAP Reinsurance Management for SAP S/4HANA

8.0 FPS02
© 2018 SAP SE or an SAP affiliate company. All rights reserved.
THE BEST RUN

Content
1 SAP Reinsurance Management for SAP S/4HANA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Cubes and Queries for Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Cube for Summary of Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Cube for Loss Triangle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Business Partners (Enhancements for SAP Reinsurance Management for SAP S/4HANA)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
3.1 Partner Functions and Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Blocking of Business Partners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Data Privacy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Managing the Lifecycle of Live and Archived Data (ILM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Read Access Logging (RAL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Risk Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Initial Screen for Processing Policies, Groups, and Participations. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Restricting the Number of Hits in a Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Mapping of Original Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Entry of Objects to Be Insured. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Liability Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
4.4 Grouping of Original Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Policy Section Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Accumulation Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.5 Definition of Participations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Cedent Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Assumed Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Retention and Ceded Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Business Involving Several Group Companies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Cession Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.6 LUD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.7 Structural Characteristics and Splits in Policy Sections and Participations. . . . . . . . . . . . . . . . . . . .131
Exclusion of Structural Characteristics/Combinations in a Policy Section or Participation. . . . . . 132
4.8 Confirmation of In-Force Business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Summarization of Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.9 Renewal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Renew Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

2 PUBLIC Content
Renew Cessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Overall Renewal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.10 Risk Manager Accounting Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Mergers and Acquisitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Transfer Exchange Rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
Risk Manager Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Accounts for Connecting Participations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Retrocession Adjustment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Flexible Summarization of Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Summary of Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Currency Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.11 Process-Oriented Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Example: Creating Assumed Treaties in Basic System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Example: Defining and Processing Class Models (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Example: Creating Ceded Master Treaties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
Example: Creating Reinsurance Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Example: Creating Portfolio Treaties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Example: Creating Accumulation Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Example: Creating Policies, Policy Sections, and Participations. . . . . . . . . . . . . . . . . . . . . . . . . 185
Example: Creating Prior Cessions (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Example: Editing Defaults for Cession Calculation Criteria (Optional). . . . . . . . . . . . . . . . . . . . .189
Example: Creating Cession Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Example: Entering Extension Service Data for Groups (Optional). . . . . . . . . . . . . . . . . . . . . . . 190
Example: Calculating Cessions and Confirmation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Example: Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5 Basic System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

5.1 Treaty. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Treaty Classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Treaty Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Working with Treaties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Where-Used List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
5.2 Treaty Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Initial Screen for Treaty Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Assigning Treaties to Treaty Groups and Removing Assignments. . . . . . . . . . . . . . . . . . . . . . . 344
Group Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Group Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
5.3 Accounting Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Non-Proportional Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Currency Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Transfer Exchange Rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Content PUBLIC 3
Time Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
Flexible Summarization of Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Use of Parallel Books (Multi-GAAP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Flexible Ledger Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
End Date of Financial Year Is Not December 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Display Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
5.4 Forecast and Estimation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413
Development Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Forecast and Estimation Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Editing Forecast and Estimation Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Relevant Parts of the Treaty Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Group Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Processing of Accounting Units in Forecast and Estimation. . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Customizing for Forecast and Estimation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Forecast and Estimation (Basic System). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
5.5 Change of Financial Year. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Management of FS-RI Financial Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
5.6 Office Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Execution and Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Consistency of Data Displayed and Customer Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
6 Current Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

6.1 Document Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467
Reinsurance Account Statement and Current Account Statement. . . . . . . . . . . . . . . . . . . . . . 467
Bordereau Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
6.2 Integration with FS-CD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
SAP Business Partner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Insurance Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Contract Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .480
Business Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Display Account Balances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Ledger Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .481
7 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

7.1 Global Accounting Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Dialog Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
7.2 Hierarchies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Maintaining Hierarchies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Class of Business Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Line of Business Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Area Structuring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

4 PUBLIC Content
Treaty Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Treaty Section Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Loss Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
8 Information System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

8.1 SAP Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
8.2 Report Painter/Report Writer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499
8.3 Fund Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Menu Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Currency Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .500
Currency Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Restricting the List of Evaluations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Program Variants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .502
8.4 RI Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Menu Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Information About Column Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .503
8.5 Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Menu Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Selecting the Data Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Information About Column Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
9 Background Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

9.1 Control Background Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .519
Task Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Log for Background Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .521
Flexible Summarization of Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
9.2 FS-RI Background Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
General Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Functions for Period-End Closing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533
Adjustment Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Mergers and Acquisitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Special Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
FS-RI Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
10 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564
10.1 APIs for Connecting Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .564
API Functions: Function Types (Function Groups). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
API Functions: Reinsurance Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
API Functions: Reinsurance Loss Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
API Functions: Reinsurance Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

Content PUBLIC 5
API Functions: Reinsurance Policy Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
API Functions: Reinsured Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
API Functions: Reinsurance Contract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
API Functions: Reinsurance Program Ruleset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
API Functions: Reinsurance Technical Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
API Functions: Reinsurance Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
10.2 BAPIs for Connecting Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
BAPIs in FS-RI Basic System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
BAPIs in FS-RI Risk Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
10.3 P2R Interface for Integration of Primary Insurance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .580
Configuration of the P2R Interface in the FS-RI System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Configuration of the P2R Interface in the PI System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595
Use Cases for the Interface (BAPIs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
11 Set Company Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
12 Cross Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

12.1 Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Single Loss Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Loss Group Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Loss Figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Managing Loss Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .686
12.2 Reinsurance Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Reinsurance Program Cession. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Functions for Editing Reinsurance Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .693
Assigning Treaties to a Reinsurance Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Creating Reinsurance Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
12.3 Bordereau Manager (Basic System and Risk Manager). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Generation of User-Specific Bordereaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .697
Creating Bordereaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Changing Bordereaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Deleting Bordereaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Copying Bordereaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Generate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Reversal of Bordereau Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Simulation of a Reversal from a Bordereau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Segmentation of Bordereau Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Balance Postings in Basic System Bordereau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Balance Postings in Risk Manager Bordereau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Bordereau with Target Balance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Bordereau Creation: Customizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
12.4 Extension Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

6 PUBLIC Content
Extendable Applications and Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Extension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Transport/Distribution to Other Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Translation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .715
BAPI and ALE Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Business Add-In (BAdI). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
12.5 External References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
12.6 Organizational Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Change Organizational Structure Initial Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
12.7 Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Method Using BP Roles (Without Organizational Management). . . . . . . . . . . . . . . . . . . . . . . . 727
Method Using Competences and Organizational Management. . . . . . . . . . . . . . . . . . . . . . . . . 730
12.8 Business Warehouse Extractors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Editing Application Component Hierarchy for BW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Extractors for Basic System Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Extractors for Basic System Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Extractors for Basic System Transaction Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Extractors for Risk Manager Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Extractors for Risk Manager Texts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Extractors for Risk Manager Transaction Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
12.9 Generation of Histories in Basic System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
12.10 Archiving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Archiving Objects in Basic System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Archiving Objects in Risk Manager Non-Life. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
12.11 Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
12.12 SAP NetWeaver Business Client Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Structure of the User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Structure of a Search Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .778
Control of Applications and Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Functions for Controlling Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Functions for Managing Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .781
Configuring Web Dynpro Applications and SAP NetWeaver Business Client. . . . . . . . . . . . . . . . 781

Content PUBLIC 7
1 SAP Reinsurance Management for SAP
S/4HANA
SAP Reinsurance Management for SAP S/4HANA (also known as FS-RI) is used to manage the master data for
active and passive reinsurance and to apply the associated rules to assumed risks or treaties and their
payment flows. It also considers the rules for accounting in accordance with the German Commercial Code
(HGB), International Accounting Standards (IAS), and other accounting principles.
Key Features
The following table explains the key features available:
Key Features Use
Management of reinsurance treaties You use this feature to document the treaties and their con
ditions in a form that can be used for subsequent functions.
Assumed treaties, ceded treaties, and the relationships be
tween treaties can be managed.
Reinsurance programs You use this feature to create the reinsurance programs or
retrocession programs for single risks and to link these pro
grams with the reinsurance treaties to be used.
Management of single risks You use this feature to record risks from your own primary
insurance or from assumed reinsurance and to determine
the applicable reinsurance or retrocession.
It is also used to group together policies for collective rein

surance or retrocession.
The system uses the rules specified in the reinsurance pro

grams to determine the applicable reinsurance or retroces
sion.
Loss management You use this feature to create losses with the most important
elements relevant for reinsurance. You can then use the ac
counting functions to calculate these losses and create ac
counts on the assumed and ceded side.

8 PUBLIC SAP Reinsurance Management for SAP S/4HANA
Key Features Use
Reinsurance account You use the accounting function to check the accuracy of in
ward accounts with regards to the contractual agreements.
This feature is also used to distribute accounts delivered on

the assumed business side to ceded coverages; the contrac
tually agreed rules are also applied in this case.
There is also an integrated function that distributes the ac

count data to the individual reinsurers, which is relevant for
ceded treaties.
The accounting function also creates the postings for the

current account system and the general ledger.

SAP Reinsurance Management for SAP S/4HANA PUBLIC 9
2 Analytics
SAP Reinsurance Management for SAP S/4HANA provides the following analytical functions for the “Account”
component:
● Query for Summary of Accounts

● Query for Loss Triangle
For more information about the analytical functions supported by SAP S/4HANA, see Analytics.
Related Information
Query for Summary of Accounts [page 13]

Query for Loss Triangle [page 20]
2.1 Cubes and Queries for Account
2.1.1 Cube for Summary of Accounts
Technical Name /MSG/I_ACCOUNTINGRESULTC
View type Composite, Cube
Release status Released
Purpose
This CDS view offers you a flexible view of the summary of accounts, depending on the parameters listed
below.
Prerequisites
● You are authorized to access the cube and dimension views used therein.

10 PUBLIC Analytics
The following authorizations objects are required:
Authorization Object Check Condition Field Value Description
SDDLVIEW Check whether the Authorization object

user has the authori relating to the display
zation object of specific CDS views
SDDLVIEW
DDLNAME /MSG/
I_ACCOUNTINGRESU
LTC
DDLSRCNAME /MSG/
I_RCSECTIOND
/MSG/
I_RICONTRACTD
/MSG/I_RILOSSD
/MSG/
I_RIOBJECTGUIDD
/MSG/
I_RIOBJECTIDD
/MSG/
I_RRPRTGUIDD
/MSG/I_RRPRTIDD
/MSG/
I_RCINVOLVEMENTD
ACTVT 03 (Display)
● You are authorized to run analytical evaluations for the “Account” business object.
/MSG/A_ACC Check whether the Authorization object

user has the authori relating to analytical
zation object /MSG/ evaluations for the ac
A_ACC count
BUKRS Company codes of Company code

the account for which
an analytical evalua
tion can be run

Analytics PUBLIC 11
/MSG/R_VTG Treaty number of the Treaty number

account for which an
analytical evaluation
can be run
ACTVT 03 (Display)
 Note
These authorization objects are independent of the existing authorization objects for accounts.
Structure
Business Objects
This view is built on the following business objects:
● RiContract
● RiTechnicalAccount
● RiObject
● RiLoss
● RiRiskParticipation
Main Input Parameters
Mandatory parameters:
● Exchange date (P_ExchangeDate)

You use this parameter to specify the exchange date for the currency translation of the original amount and
of the amount posted. The current date is used as the default.
● Exchange rate type (P_ExchangeRateType)
You use this parameter to specify the exchange rate type for the currency translation of the original
amount and of the amount posted.
● Display currency (P_DisplayCurrency)
You use this parameter to specify the target currency for the currency translation of the original amount
and of the amount posted.
● Accounting principle (AccountingRegulationCode)
Measures and Attributes
As a result, this query provides the following measures for the grouping of treaty/section, entry code number,
account cedent, and reinsurer:
● Original amount (OriginalAmount)

● Original amount in display currency (OriginalAmountInDisplayCrcy)
● Amount posted (AccountingAmount)
● Amount posted in display currency (AccountingAmountInDisplayCrcy)

12 PUBLIC Analytics
You can refine your data analysis using a variety of attributes:
● Account status (StatusCode)

● Occurrence year (OccurrenceYear)
● Financial accounting date (FinancialPostingDate)
● Financial year (FinancialYear)
● Treaty category (RCUseCode)
Example Query
SAP Reinsurance Management for SAP S/4HANA provides the following example query for this cube: Query for
Summary of Accounts [page 13].
Constraints
● The system’s performance is directly dependent on the amount of data to be selected; the wider your
selection, the longer the runtime and the greater the memory used.
● The exchange date for the currency translation has the same effect on all postings.
2.1.1.1 Query for Summary of Accounts
Technical Name /MSG/C_ACCOUNTINGRESULTQ
View type Consumption, Query
Purpose
You can use the query /MSG/C_AccountingResultQ to create a flexible view of the summary of accounts.
Related Cube
The results of this query are obtained using the following cube: Cube for Summary of Accounts [page 10].

Analytics PUBLIC 13
Prerequisites
● You are authorized to access accounts. The following authorization objects are required for this query:

SDDLVIEW
DDLNAME /MSG/
C_ACCOUNTINGRESU
LTQ
DDLSRCNAME /MSG/
I_ACCOUNTINGRESU
LTC
ACTVT 03 (Display)
 Note
● You have the authorizations required for the related cube for the summary of accounts.
Starting the Query
You start the data analysis of accounts by entering the following parameters:

You use this parameter to specify the exchange date for the currency translation of the original amount and
of the amount posted. The current date is used as the default.
amount and of the amount posted.
You use this parameter to specify the target currency for the currency translation of the original amount
and of the amount posted.
● Combination of actual and estimate (NatureCombinationCode)
● Accounting principle (AccountingRegulationCode)
● Module (CategoryCode)
Optional parameters:

14 PUBLIC Analytics
● Company code (CompanyCode)
● Accounting year (ClientAccountingPeriodYear)
● Treaty number (multiple selection and selection by area possible) (RiContractInternalID)
● Account status (multiple selection possible) (StatusCode)
Query Results and Data Analysis
As a result, this query provides the following measures for the grouping of treaty/section, entry code number,
account cedent, and reinsurer:
● Original amount (OriginalAmount)

● Amount posted (AccountingAmount)
● Amount posted in display currency
● Account status (StatusCode)

● Occurrence year (OccurrenceYear)
● Treaty category (RCUseCode)
Constraints
2.1.2 Cube for Loss Triangle
Technical Name /MSG/I_LOSSTRIANGLEC
View type Composite, Cube

Analytics PUBLIC 15
Purpose
You can use the cube /MSG/I_LossTriangleC to create a loss triangle.
This cube helps you to analyze losses and reserves so that you are able to answer the following questions, for
example:
● To what extent are reserves needed for subsequent years?

● For how long do loss payments have to be made?
● How has the reserve balance changed?
Prerequisites
● You are authorized to access the cube and dimension views used therein.

SDDLVIEW
DDLNAME /MSG/
I_LOSSTRIANGLEC
DDLSRCNAME /MSG/
I_UNDERWRITINGAR
EAD
/MSG/
I_LINEOFBUSINESS
D
/MSG/
I_CLASSOFBUSINES
SD
/MSG/I_RILOSSD
/MSG/
I_RCINVOLVEMENTD
/MSG/
I_RICONTRACTD
/MSG/
I_RCSECTIOND

16 PUBLIC Analytics
ACTVT 03 (Display)
● You are authorized to run analytical evaluations for the “Account” business object.
/MSG/A_ACC Check whether the Authorization object

user has the authori relating to analytical
zation object /MSG/ evaluations for the ac
A_ACC count
BUKRS Company codes of Company code

the account for which
an analytical evalua
tion can be run
/MSG/R_VTG Treaty number of the Treaty number

account for which an
analytical evaluation
can be run
ACTVT 03 (Display)
 Note
● The analysis is created taking into account the Customizing settings under FS-RI Reinsurance Basic
System RI Statistics Define Layouts for Statistical Evaluations .
The calculations for the loss triangle use only postings whose entry code is defined as relevant in this
Customizing activity. Make the following Customizing settings:
1. In the Layout Header (P/L Model) dialog structure, define the attributes Company Code (CoCd) and
P/L Model as key attributes.
These key attributes are used to determine the profit and loss model based on the entries for the cube
parameters Company Code for P&L Model (P_CompanyCode) and Profit and Loss Model (P_PLModel).
It must be possible to identify a row in the layout header that corresponds to the entered parameters.
Enter a short and a long name as well.
2. In the Report Rows dialog structure, make the necessary assignments for the entries in the Layout
Header (P/L Model) dialog structure from point 1.
This is used to define the rows of the loss triangle, such as losses and reserves.
For each row, enter a unique number for the P/L row (P/L Row No) with a short name for the row
number (P/L Row) and a long name.
Only 1 (single row) is permitted as the line usage indicator (Line Usage). Enter +1 or, if you want to
reverse the results, -1 as the plus/minus factor. You can choose between the reserve type “ ” (for
losses), “1” (for opening reserves), and “2” (for closing reserves). The system analyzes in the loss
triangle only rows that you have defined as losses or closing reserves.

Analytics PUBLIC 17
3. In the Assign Entry Codes dialog structure, make the necessary assignments for the entries in the
Layout Header (P/L Model) dialog structure from point 1.
This is used to assign entry codes to the layout header (P/L model) and the report row.
Enter in the Financial Year Row attribute the report row to which you want each individual entry code to
belong.
The Previous Year Row (Prev. Yr Row) attribute is not relevant for the loss triangle.
For example, all loss entry codes are assigned here to the row called “Losses”.
The Quotient Rule and the Aggregation Rules dialog structures are not relevant for the loss triangle.
Structure
Business Objects
This view is built on the following business objects:
● RiContract
● RiTechnicalAccount
● RiObject
● RiLoss
Main Input Parameters
● Start of occurrence year (P_StartYear)

You use this parameter to specify the occurrence year from which you want to calculate the loss triangle.
● End of occurrence year (P_EndYear)
You use this parameter to specify the occurrence year to which you want to calculate the loss triangle.
amount.
You use this parameter to specify the target currency for the currency translation of the original amount.
You use this parameter to specify the exchange date for the currency translation of the original amount.
The current date is used as the default.
● Accounting principle (Acc. Princ.; P_AccountingRegulationCode)
The system analyzes only postings whose entry code is contained in the specified accounting principle.
You can also use this accounting principle to control whether the accounting year or the financial year is
used for calculations in the columns of the loss triangle.
To find out the year on which an accounting principle is based, see the Customizing settings under FS-RI
Reinsurance Basic System Accounting Accounting Principles Edit Accounting Principles .
● Company code for P&L model (P_CompanyCode)
When you enter the company code and the Profit and Loss Model parameter (P_PLModel), the query uses
the entry defined in Customizing under FS-RI Reinsurance Basic System RI Statistics Define
Layouts for Statistical Evaluations to evaluate the data.
The company code is not taken into account when the postings are selected.
● Profit and loss model (P_PLModel)

18 PUBLIC Analytics
When you enter the profit and loss model and the Company Code parameter (P_CompanyCode), the query
uses the entry defined in Customizing under FS-RI Reinsurance Basic System RI Statistics Define
● Module (P_CategoryCode)
The system analyzes only postings with the specified module. It is only possible to select accounts and
postings from Basic System or Risk Manager.
Measures and Attributes
Some important measures and attributes are:
● Measure
○ Original amount in display currency (OriginalAmountInDisplayCrcy)
This displays the totaled amounts in the specified display currency. The amounts are assigned the
correct plus/minus sign in accordance with the Customizing settings for the P/L model and the related
treaty.
● Attributes
○ Occurrence year (OccurrenceYear)
○ Development year (DevelopmentYear)
In accordance with the specified accounting principle, the development year specifies either the
accounting year or the financial year of the corresponding account. If you set this attribute as a column
the system displays the preliminary step of the loss triangle as the result.
○ Year (DevelopmentYearDifference)
This specifies the difference between the occurrence year and the development year. If you set this
attribute as a column the system displays the loss triangle as the result.
○ Year basis (DevelopmentYearBasis)
This contains as its only value the year (financial year or accounting year) used to calculate the
development year.
○ Name (Type)
This returns the name of the report row in Customizing under FS-RI Reinsurance Basic System
RI Statistics Define Layouts for Statistical Evaluations .
Example Query
SAP Reinsurance Management for SAP S/4HANA provides the following example query for this cube: Query for
Loss Triangle [page 20].
Constraints
● Only the original amount is provided as a measure.

Analytics PUBLIC 19
2.1.2.1 Query for Loss Triangle
Technical Name /MSG/C_LOSSTRIANGLEQ
View type Consumption, Query
Purpose
You can use the query /MSG/C_LossTriangleQ to create a loss triangle.
This CDS view helps you to analyze losses and reserves:
● To what extent are reserves needed for subsequent years?

● For how long do loss payments have to be made?
● How has the reserve balance changed?
Related Cube
The results of this query are obtained using the following cube: Cube for Loss Triangle [page 15].
Prerequisites
● You are authorized to access accounts.

The following authorization objects are required for this query:

SDDLVIEW
DDLNAME /MSG/
C_LOSSTRIANGLEQ
DDLSRCNAME /MSG/
I_LOSSTRIANGLEC

20 PUBLIC Analytics
ACTVT 03 (Display)
 Note
● The prerequisites for the related loss triangle cube are also relevant.
Starting the Query
You start the data analysis of accounts by entering the following parameters:
● Start of occurrence year (P_StartYear)

You use this parameter to specify the occurrence year from which you want to calculate the loss triangle.
● End of occurrence year (P_EndYear)
You use this parameter to specify the occurrence year to which you want to calculate the loss triangle.
amount.
You use this parameter to specify the target currency for the currency translation of the original amount.
You use this parameter to specify the exchange date for the currency translation of the original amount.
The current date is used as the default.
● Accounting principle (P_AccountingRegulationCode)
The system analyzes only postings whose entry code is contained in the specified accounting principle.
You can also use this accounting principle to control whether the accounting year or the financial year is
used for calculations in the columns of the loss triangle.
To find out the year on which an accounting principle is based, see the Customizing settings under FS-RI
Reinsurance Basic System Accounting Accounting Principles Edit Accounting Principles .
● Company code for P&L model (P_CompanyCode)
When you enter the company code and the Profit and Loss Model parameter (P_PLModel), the query uses
the entry defined in Customizing under FS-RI Reinsurance Basic System RI Statistics Define
The company code is not taken into account when the postings are selected.
● Profit and loss model (P_PLModel)
When you enter the profit and loss model and the Company Code parameter (P_CompanyCode), the query
uses the entry defined in Customizing under FS-RI Reinsurance Basic System RI Statistics Define
● Module (P_CategoryCode)
The system analyzes only postings with the specified module. It is only possible to select accounts and
postings from Basic System or Risk Manager.

Analytics PUBLIC 21
Optional parameters:
● Business type number (multiple selection possible) (BusinessTypeCode)

The system analyzes only postings with the specified business type numbers.
● Underwriting area (UnderwritingAreaCode)
You can use this parameter to filter by an area node. The result contains only postings that occurred in a
subarea of the specified area parameter.
● Class of business number (ClassOfBusinessCode)
You can use this parameter to filter by a class of business node. The result contains only postings that
occurred in a sub-class of business of the specified class of business parameter.
Query Results and Data Analysis
As a result, this query provides the following measures for each occurrence year (row) and accounting year or
financial year (column):

This displays the totaled amounts in the specified display currency. The amounts have the plus/minus sign
resulting from the Customizing layout for statistical evaluations, from the plus/minus sign of the entry
code and from the plus/minus sign of the related treaty.
● Occurrence year (OccurenceYear)

This is defined by default as a row so that the result represents a loss triangle.
● Development year (DevelopmentYear)
In accordance with the specified accounting principle, the development year specifies either the
accounting year or the financial year of the corresponding account. If you define this attribute as a column
the system displays the preliminary step of the loss triangle as the result.
● Year (DevelopmentYearDifference)
This specifies the difference between the occurrence year and the development year. If you set this
attribute as a column the system displays the loss triangle as the result.
● Year basis (DevelopmentYearBasis)
This contains the year used to calculate the development year (financial year or accounting year) as its
only value. This attribute is defined as a column by default.
● Name (Type)
This returns the name of the report row in Customizing under FS-RI Reinsurance Basic System RI
Statistics Define Layouts for Statistical Evaluations .
Constraints
● Only the original amount is provided as a measure.

22 PUBLIC Analytics
3 Business Partners (Enhancements for
SAP Reinsurance Management for SAP
S/4HANA)
Use
You use the standard SAP Business Partner application to maintain business partners in SAP Reinsurance
Management for SAP S/4HANA (FS-RI); the program functions therefore comply with the standard SAP
system.
For more information about SAP Business Partner, see the documentation under Cross-Application
Components SAP Business Partner (SAP BP) .
Features
The specific requirements for reinsurance (FS-RI system) are described below.
In addition to the SAP standard role types, the following additional role types exist in the FS-RI system:
● Organizations:
○ Cedent
○ Reinsurer
○ Broker
○ Group company
○ Account recipient
○ Owner company
○ Managing general agent (MGA)
○ Third-party administrator (TPA)
● Natural persons:
○ Contact person
○ Responsible for treaty
○ Responsible for account
○ Responsible for loss
○ Responsible for RM
○ Responsible for group
○ Responsible for object
○ RI policyholder
○ Contact person for printing
○ Responsible for loss account
Additional Maintenance Options

Business Partners (Enhancements for SAP Reinsurance Management for SAP S/
4HANA) PUBLIC 23
The additional options available for maintaining business partner data in the FS-RI system are contained on the
Reinsurance tab page.
This screen is divided into the following sections.
Organizational Data
This section contains the following fields, which provide information about structures or the organizational
plan: This includes:
● Company Code
A link is established for the owner company between the actual company and the corresponding company
code. This defines the independent accounting unit behind each partner.
● Transferred To
● Business Partner Grouping
This mechanism offers an alternative to the business partner relationships in the standard system. The FS-
RI Business Partner menu contains a Grouping option. This is a general option for defining hierarchies.
Reference to the hierarchies stored here can be made in this field by selecting a node using the input help
and setting it for the partner.
● Official Company ID
The Association of German Property Insurers (VDS) maintains a list of IDs for partners in the insurance
sector. You can enter the ID for the partner, provided you have maintained the corresponding data in
Customizing under Basic System Business Partners Maintain Reinsurance Enhancements . In the
Customizing activity Activate/Deactivate Check for Official Company IDs, you can deactivate the check that
is performed against the list of VDS codes.
● Area
In this field you can enter the area in which the partner is active. While the region in which the partner is
resident is stored in the standard SAP system, you store information about the partner’s sphere of activity
here. You can also enter any FS-RI area hierarchy node. You enter the relevant area hierarchies under
Master Data Hierarchies .
● Organizational Unit and Position
You enter the organizational unit or position of the partner (in this case, the employee in the customer’s
company) for all partners who are persons responsible (for example, responsible for the treaty). You
maintain organizational units and positions in the Organizational Plan. You can also maintain these in
Customizing for Basic System under Basic Settings Organizational Management . You use the
“Choose Organizational Plan” activity to indicate that data is taken from the Organizational Plan (Dept/Pos.
checkbox is not selected) or you use the Define Departments and Positions (FS-RI Method) activity to
indicate that data is taken from FS-RI Customizing. You enter an FS-RI partner as the person responsible in
each relevant business object in the FS-RI system (for example, treaty, account, or group). When you want
to access the object, the system checks the assigned authorization against the data for the Organizational
Plan entered here.
● Portfolio Treaty
If you know the reinsurance program for the cedent, you can use this portfolio treaty to indicate, in the case
of from ground up (FGU) loss accounts, the treaty sections that cover the relevant entry. This is particularly
important for external system control via BAPIs. It therefore makes sense to enter a portfolio treaty for
partners with the role of Cedent.
● Days per Year Rule
You can enter a days per year rule here for business partners with the role of Cedent and Reinsurer. The
following values are available:
○ 360 days

24 PUBLIC 4HANA)
○ 365 days
○ 366 days
This rule is used by the Calculate Unearned Premiums [page 246] background job when it calculates
unearned premiums using the method Accruals/Deferrals Up To Period End. It is also used to calculate the
reinstatement premium or reinstatement reserve within the non-proportional account. The days per year
rule defines the weighting for individual months. If a value is not entered, the system applies a 336 day rule.
The entries apply to calculations in Basic System only. For Risk Manager functions, the day rule is taken
from the default values for the Risk Manager account.
Account Data
Data that is important for accounts, and therefore for cash management, is stored in this section.
This includes:
● Company No.
● Business Partner Status
The business partner status that can be defined here can be set in Customizing for Basic System under
Business Partners Maintain Reinsurance Enhancements . You can give the status any name; it also
has an attribute (the lock level) that allows you to lock the partner for certain activities, for example, for
concluding new treaties. No checks are performed in the FS-RI system.
● Currency
In this field, you enter the currency in which the partner usually works. This field refers to standard SAP
Customizing.
● Payment Lock
You set this checkbox if no more payments are to be made to a partner. The relevant functions in the FS-RI
account evaluate this field.
● Current Account Assignment Table
You can use this table to assign an account in the current account system to a partner for each relevant
company code. In FS-CD, this is a contract account. When you save the partner, the system transfers the
data to the connected current account system via an active interface. In the Customizing settings for the
account, you can specify which account current system is connected in which company code. You do this
in Customizing for Basic System under Default Values Edit Defaults for Accounting . You define the
company codes entered by default in this table in Customizing for Basic System under Business Partners
Maintain Reinsurance Enhancements Maintain Customer Master Data Interface . The accounts are
assigned in the table in accordance with the Customizing settings. If you specify internal number
assignment for the account (the customer), # is entered as the account category. When you save the
account, the system replaces this character with the category determined by the current account system.
Partner Rating
In this subsection, you can enter your own ratings for a partner; for example, you can enter ratings for the
relevant agencies here. In Customizing, you can use a three-step procedure to specify the values to be
permitted for the source (agency) and rating category (for example, financial strength). You can select the
entries made in Customizing in the partner rating table. You can use the Note field to enter user-defined text.
Additional Data
The additional data section contains two checkboxes that can be set as appropriate for the partner. If you want
the partner to receive a Christmas gift you have to set the corresponding checkbox. The same applies to
Christmas greetings. The appropriate functions can then be used to evaluate which partner is considered for
the relevant bonuses.

4HANA) PUBLIC 25
Lock for Role Usage
In this subsection, you can lock the usage of a business partner in a certain role in the FS-RI system for a set
period. You must assign one lock reason and one lock level to a role lock. You define the lock reason in
Customizing and you define the error text and warning level (warning or error) to be displayed if this business
partner is used. The lock level indicates whether the lock is Relevant for New Entry or Relevant for Account and
New Entry.
Data Privacy
The following functions are available when you enter business partners:
● Check whether natural or legal persons are used

● Delete business partner references in policy or object
These functions support you when you check whether business partners (natural or legal persons) are used in
active business relationships. If a business partner is no longer involved in active business relationships, the
system records this when it checks whether natural or legal persons are used. At the end of the statutory
retention period, you can physically delete and archive the references and historical data for this business
partner, taking into account any dependencies to connected systems.
3.1 Partner Functions and Roles
You can define partner functions for correspondence and payment transactions, as well as for information
purposes, in Customizing for Basic System under Treaty -> Edit Partner Functions. You can then assign specific
roles to these partners. In this Customizing activity, you can select a partner function and assign a business
partner with the corresponding partner role.
The partner functions delivered with the standard system are Account Recipient (for premium/loss) and
Payment Partner (for premium/loss). You use these partner functions to define the account recipient and
payment partner for accounting purposes. If you do not enter details for the partner functions in the treaty, the
system automatically uses the partner involved for the reinsurance account/current account statement.
In Customizing you can indicate that partner functions are mandatory (for reinsurer or cedent shares for a
partner involved), and specify whether the address and contact person are required entries. When you enter a
partner, the system then enters the standard address and contact person specified for the business partner as
the default value.
3.2 Blocking of Business Partners
Use
You use this function if your company stops working with a business partner or if you want to restrict the use of
a business partner. The FS-RI solution offers you a flexible lock logic that you can apply specifically to individual
roles for the business partner (for example, “Cedent”) and specific activities (for example, “Create Treaty”).

26 PUBLIC 4HANA)
Features
You can lock a business partner for a certain period of time and for any combination of modules (Basic System,
Risk Manager Non-Life, and Risk Manager Life).
You can set any number of locks for a business partner and these can also overlap.
You define the exact function of a lock using the following attributes.
● Locked roles
A lock always relates to only one specific role held by the business partner. If you want to lock a business
partner in all its roles, you must lock it in each role.
● Lock levels
The lock level defines the activity for which the business partner is locked. The FS-RI system provides three
default lock levels. If you want to lock a business partner for all functions, you must lock it at all levels.
○ Relevant for new entry
The system does not allow you to create a new treaty with this business partner in the locked role, or it
displays a warning to this effect (depending on the warning level for the lock reason).
This function applies to both the manual creation of a treaty and to the creation of a treaty with a
template or by copying (the check is restricted to the role of cedent).
○ Relevant for account
The system does not allow you to create an account with this business partner in the locked role, or it
displays a warning to this effect (depending on the warning level for the lock reason).
○ Relevant for renewal
The system does not allow you to create a new period in a treaty with this business partner in the
locked role, or it displays a warning to this effect (depending on the warning level for the lock reason).
This function applies when you create a period manually, when a period is created by a BAPI and when
the status of a period is set to “Posting Allowed”.
● Lock reasons
You must enter a lock reason for each lock. The lock reason indicates to other users why a role was locked;
the warning level for the lock reason influences how the system reacts after a role is locked. You define lock
reasons in external Customizing for Basic System under Business Partners Maintain Reinsurance
Enhancements Reasons for Role Lock .
Warning Levels
Each lock reason has the warning level "W" (warning) or "E" (error). If the warning level is "W" and you try to
use a business partner in a locked role or function, the system displays a warning but allows you to use the
business partner in this role or function. However, if the warning level is "E", the system does not allow you
to use the business partner in this role or function and issues an error message.
Activities
To lock a business partner, proceed as follows:
1. Process the business partner to be locked in a role relevant for reinsurance and switch to the
“Reinsurance” tab page.
2. Set the required locks in the section “Lock for Role Usage”.
3. Save your entries.

4HANA) PUBLIC 27
3.3 Data Privacy
Use
The following functions are available for data privacy:
● Managing the lifecycle of live and archived data (ILM) [page 28]
● Read Access Logging (RAL) [page 32]
3.3.1 Managing the Lifecycle of Live and Archived Data (ILM)
Use
The following functions are available when you enter business partners:
● Check whether natural or legal persons are used [page 30]
● Depersonalizing business objects [page 29]
These functions support you when you check whether business partners (natural or legal persons) are used in
active business relationships. If a business partner is no longer involved in active business relationships, the
system records this when it checks whether natural or legal persons are used in the business partner. At the
end of the statutory retention period, you can depersonalize the business objects and any historical data that
reference this business partner, taking into account any dependencies to connected systems, and then archive
the business partner.
More Information
For more information about the use of SAP Information Lifecycle Management (ILM) functions, see the
corresponding documentation on help.sap.com under Cross Applications SAP NetWeaver Information
Lifecycle Management .

28 PUBLIC 4HANA)
3.3.1.1 Depersonalizing Business Objects
Prerequisites
● You have run the end of purpose (EoP) check in transaction BUPA_PRE_EOP.
● You have created archiving object /MSG/XDP (FS-RI Data Privacy) and assigned the report as a delete
program.
Context
The technical name of this background job is /MSG/X_BUSINESS_PURPOSE_DELETE.
You can run this report to use ILM functions to depersonalize business objects containing references to
business partners that are no longer involved in active business relationships.
 Note
This is not an archiving program.
Procedure
1. The system uses authorization object B_BUP_PCPT to check whether you have the necessary
authorization.
2. After it has checked whether the business partners are still being used, the system uses archiving
object /MSG/XDP to depersonalize the business objects containing references to the business partner
being archived.
3. The system uses archiving object CA_BUPA to archive the business partners that are no longer used.
Results
The report has depersonalized all business objects containing references to business partners that are no
longer used. The following objects are affected:
● Assignments between business partner and policy on the Partners Involved tab page in the operational
data
● Assignments between business partner and policy on the Partners Involved tab page in the history data
● Assignments between business partner and object in the operational data

4HANA) PUBLIC 29
● Assignments between business partner and object in the history data
The system does not display any personal data related to the business partner, including the business partner
number. You cannot view or change any information. You cannot create any new business relationships with
this business partner.
3.3.1.2 Check Whether Natural or Legal Persons Are Used
Use
The technical name of this background job is /MSG/RP_FSRI_BUPA_EOPK_CHECK.
You can use this function module to check whether a natural or legal person (whose business partner category
is "Person" or "Group") is used as the partner involved in a policy or in an object and whether this business
relationship is still active.
 Note
In the meantime, you can continue to use business partners and assign policies or objects. To ensure that
inconsistent data does not arise in the time between the check to determine whether natural or legal
persons are used and the depersonalization of policies and objects, you have to run these functions one
after another as closely as possible.
Prerequisites
● You have defined the following parameters in the Customizing activity Define and Store Application Names
for EOP Check:
○ Maintenance view: V_BUTEOPAPP
○ Application name: FSRI
○ Application description: FS-RI: GESCHÄFTSPARTNER
● You have defined the following parameters in the Customizing activity Application Function Modules
Registered for EOP Check:
○ Maintenance view: V_BUTEOPFM
○ Application name: FSRI
○ Policy section: 1000000
○ Function module: /MSG/RP_FSRI_BUPA_EOP_CHECK
Procedure
Check Whether Natural Persons Are Used

30 PUBLIC 4HANA)
If you have registered the function module /MSG/RP_FSRI_BUPA_EOP_CHECK, the system runs the following
checks:
1. The system checks the following:

○ Whether a natural person has been assigned to a policy as a partner involved
○ Whether an object that contains the natural person as the business partner is assigned as follows:
○ In the policy data
○ In the policy group data (accumulation)
○ On the Policy Section Data, Group Header, Participation Data, Coverage, or Premium tab page
○ To a value insured or to a loss
A business relationship is regarded as ended if the following applies:
○ All the header data for a policy or accumulation is reversed and posting is not allowed
○ All the periods of a policy section, cession group, or participation are reversed and posting is not
allowed
○ All the policy section periods of coverages, premiums, and values insured that match the assignment
period are reversed and posting is not allowed
Or
○ All losses have the status “Completed” or “Invalid”
2. The system checks whether the Retention Period defined in ILM Customizing has expired on the current
date.
Check Whether Legal Persons Are Used
You can analyze the use of legal persons using a customer-specific enhancement (Business Add-In
(BAdI) /MSG/XP_DATA_PRIVACY_BADI).
For more information about the functional scope of BAdI /MSG/XP_DATA_PRIVACY_BADI, see the
corresponding system documentation.
Result
Result
For the purposes of the check, the system identifies the most recent change date as the “end of the business
relationship” and displays the following data in the ILM application log:
● “Current business relationship”:

○ This is set by default for an organization (legal person). You can override this using BAdI /MSG/
XP_DATA_PRIVACY_BADI.
○ For natural persons who have at least one active business relationship
○ For natural persons for which the system has found an “end of the business relationship” but for which
the retention period has not yet expired
 Note
Run the check again in twelve months.
● “No business relationship”: For natural persons:

○ Who are not assigned to a policy or to an object

4HANA) PUBLIC 31
○ Whose objects are not assigned to a policy or to a loss
● “Closed business relationship”: For natural persons for which the system has found an “end of the business
relationship” and for which the retention period has expired.
3.3.2 Read Access Logging (RAL)
Use
FS-RI provides a sample configuration for Read Access Logging (RAL) that was created based on Web Dynpro
applications and RFC modules. The content of this configuration is based on the legal definition for specific
categories of personal data.
You use this function to log access to sensitive data. This enables you to identify and close possible security
breaches.
More Information
For more information about the use of SAP Read Access Logging (RAL) functions, see the corresponding
documentation on help.sap.com under Cross Applications Data Privacy Read Access Logging (RAL) .

32 PUBLIC 4HANA)
4 Risk Manager
Use
Risk Manager (RM) is an optional FS-RI component that enhances Basic System to include functions for
managing single risks (policies) and accumulations, and for processing the corresponding accounts.
Integration
Risk Manager can be used only in conjunction with Basic System. Basic System functions are required in the
following cases:
● If you use Risk Manager to map participation in a policy, you assign the participation to one or more
assumed reinsurance treaties in Basic System. You assign ceded participations to ceded master treaties in
Basic System.
● Risk Manager cannot transfer postings directly to a system for accounts receivable/payable. Postings are
always transferred indirectly via Basic System.
● To structure the Risk Manager portfolio in order to create cession groups, you need to use a dummy treaty
from Basic System (portfolio treaty).
Features
Mapping Facultative Reinsurance Business
You can use Risk Manager 6.00 to map the entire insurance and reinsurance structure for an original policy. You
can structure the business according to:
● Original business (mapped by the original policy)

● Participations by other business partners who come between your company and the original policy in the
reinsurance chain (optional)
● Assumed participation of your own company
● Participations ceded to reinsurers/retrocessionaires (optional). This is supported by functions for the
automatic cession of risks to reinsurance treaties and for the manual distribution of the unplaced risk.
Managing Accumulations
When you enter a loss, you can assign an accumulation or several accumulations for information purposes.
Risk Manager also supports the automatic determination of accumulation groups and the joint reinsurance of
accumulations.
Entering and Settling Premiums and Losses

Risk Manager PUBLIC 33
You can enter premiums manually in the RM account, or use an automatic system run to generate the expected
premiums (under certain circumstances). If a loss occurs, you can enter it in the system and also create
corresponding accounts.
Constraints
● You can map scenario limits using the limit, underlying and deductible (LUD) function. Consequently,
scenario limits are not offered as a separate function.
● The standard system does not support PML scenarios.
● Market loss assignments, loss assignments to original policies, and loss assignments to cedents are not
supported. Consequently, it is not possible to process losses further from these levels.
4.1 Initial Screen for Processing Policies, Groups, and

Participations
Use
The initial screen for editing policies and participations is the entry point for creating all the objects for
mapping risks in Risk Manager (policy, policy section, group, and participation). You can also search for these
object categories here. You find the functions for editing policies, groups, and participations on the FS-RI:RM
(Non-Life) – Selection screen (transaction /MSG/H_RISK1).
The initial screen manages the following object categories:
● Policy
● Participation
● Group
● Policy section
Procedure
Creating a Risk Manager Object
1. Enter the object category.

2. If you want to assign the object number manually (as opposed to automatic number assignment), enter
the number of the object in the corresponding field.
3. Choose the Create pushbutton for Group, Policy, or Policy Section.
 Note
You can create a participation only from within the assigned policy section. For more information, see
Definition of Participations [page 87].

34 PUBLIC Risk Manager
Searching for a Risk Manager Object
1. Enter your search criteria on the corresponding tab pages.

2. Select which object categories you want to search for (“group”, “policy”, “policy section”, and
“participation”).
3. Choose the starting point for the search. This determines whether the system looks for all the policy
sections for a group, for example, or all the groups for a policy section.
4. If you want, adjust the required number of hits. For more information, see Restricting the Number of Hits in
a Search [page 35].
5. Confirm your entries or choose Find.
The system displays the result of your search.
The system finds all the objects that correspond to the selected categories and selection criteria. If the
selection criteria relate to other objects, the system selects the objects that are linked to the object specified in
the search. For example, if you enter the class of business “Fire” as a search criterion on the Policy Section tab
page, the system returns only policies that contain a policy section with this class of business.
You can use the Display Assignments function to find any related objects. When you select an object on one of
the tab pages in the results, this function restricts the search result on all tab pages to the assigned object.
Displaying a Risk Manager Object
Set the mode to “Display” and open the object.
Changing a Risk Manager Object
Set the mode to “Change” and open the object.
4.2 Restricting the Number of Hits in a Search
Context
On all Risk Manager initial screens you can restrict the maximum number of results that are displayed for a
simple or extended search by entering a number of hits:
● Contract Manager (depending on the starting point for the search)

● Risk Manager account
● Risk Manager bordereau
● Object Manager
This enables you to reduce search criteria and therefore avoid lengthy response times to search queries. In the
standard system, the number of hits is set at “200” by default.
For performance reasons, if you perform a search in Contract Manager with the number of hits “0” the system
displays only up to a maximum of 100,000 hits. On all other screens, it displays all the selected data.
When you perform a search in Contract Manager, the maximum number of hits always relates to the objects
specified at the starting point of your search.

When you search in a Risk Manager account, the maximum number of hits always relates to accounts if you
have entered search criteria exclusively for accounts. If not, the maximum number of hits relates to postings.
The system returns the most current results, sorted as follows:
● Contract Manager: sorted in descending order by creation date and time

● Risk Manager account: sorted in descending order by account or posting number
● Risk Manager bordereau: sorted in descending order by creation date and time
● Object Manager: sorted in descending order by creation date and time
The specified number of hits determines the number of hits within which the system sorts the results to be
displayed by search object ID.
Procedure
1. Fill the Maximum Number of Hits field.

2. Start the search.
Results
The search result is displayed in the required scope in a selection list for each screen.
4.3 Mapping of Original Business
Use
This process describes how to map the original business in the FS-RI system.
Process
1. Optional: You can define the objects [page 37] to be insured by the policy. If you do not define the objects,
you can enter the liability in the policy. It makes sense to define the objects if you have several policies
relating to the same object and you want to be able to recognize accumulations.
2. Create a policy [page 48] containing the basic insurance data.
3. Create the policyholder [page 48] for the policy.
4. Create policy sections [page 49] for the policy, which define the scope of the liability covered by the
policy.
5. Optional: You can also define coverage details for the policy sections (objects, premiums, values insured).

6. Execute the liability aggregation [page 75] function to determine the total liabilities for each class of
business and policy section from the various objects.
 Recommendation
We recommend that you carry out the steps outlined in this part of the documentation structure first, and
initially ignore the tab pages for groupings and participations within the policies and policy sections.
Result
You have entered the original business and the system has calculated the relevant liability totals for reinsurance
for each policy section. In the next step, you can group policies and accumulations into further groups, for
which you can then create participations [page 87].
Example
For an example of the process, see Example: Creating Policies, Policy Sections, and Participations [page 185].
4.3.1 Entry of Objects to Be Insured
Use
You initially enter an object [page 38] (the subject of an insurance policy) independently of the insurance
cover and then assign this later. Objects can be assigned to the following:
● Loss
● Policy group
● Policy
● Item
● Subcoverage
● Value insured
● Premium
● Participation
Process
You can use two applications to enter objects (see also Editing Objects and Object Groups (Classical SAP
Interface) [page 39] or Editing Objects and Object Groups (NWBC Interface) [page 46]).

Depending on the object category, the object can be linked to a partner that has been created as an SAP
business partner in the system. This is useful for life insurance business, where personal data about the
policyholder needs to be stored in the system.
The object category can also be a material object, such as a ship, airplane, or building. You can enter the exact
features and characteristics for each specific object category.
Objects can also be arranged into object groups, whereby each object group also represents an object and can
likewise be assigned to an object group. The object group itself can then be linked to a coverage (such as for a
fleet of airplanes).
4.3.1.1 Object
Definition
The object is the entity being insured, such as a building, a ship, or the life of a person.
The assigned object category describes the object characteristics, which are specific to particular classes of
business. You can enter data relating to the property (for example, auto, equipment, and ship), location (such
as the insurance location) and individuals (such as the name and date of birth).
Use
Description of Treaty and Policy Sections and Losses
You can define objects independently of policies or treaties and then enter these in the following contexts to
indicate that these areas relate to this object:
● Treaty participations
● Policy groups
● Policies
● Policy sections
● Coverages within policy sections
● Premiums and values insured within coverages
● Losses
The assignment of an object to one of these contexts is always restricted by the validity period of the
assignment. The validity period of the assignment cannot be longer than the validity period of the object itself.
You can enter various object details to help you evaluate the insurance for the object in question.
Accumulation Control
The Risk Manager Non-Life accumulation function also uses the objects specified in the policy sections to
identify policy sections that relate to the same object and group them as accumulations.
Object Group
You can bundle objects in object groups.

If you want to assign the object to an object group higher up in the hierarchy, you enter the ID of the object
group in this field. This prevents circular assignments, especially in longer chains.
 Example
Object group 1 is assigned to object group 2 and object group 2 is assigned to object group 1. This is a
circular assignment. The assignment A B C A would be incorrect.
Structure
Each object has a unique ID and is defined by the following:
● A user-defined name
● Object category (such as building, power station, natural person)
You define the object categories in Customizing for FS-RI Reinsurance under FS-RI Risk Manager (Non-
Life) Object Management Maintain Object Categories .
● Area
● Longitude and latitude (only available in objects in NWBC loss applications)
● Information about the natural person (dependent on the object category; only available in objects in NWBC
applications)
● Validity period
● Business partner insuring the object (dependent on the object category)
● Your own classification characteristics that you implemented with an Extension Service (optional)
4.3.1.1.1 Classical Object Processing
Use
The following describes the procedures for editing objects, object groups, and object relationships using
classical SAP applications.
 Caution
For technical reasons, an object group is regarded as an object in which the Object Group checkbox has
been set. This means that you can assign subobjects to this object. For this reason, you can often use the
same initial screen to create an object group as you use to create an object.
For more information about the structure and use of objects, see Object [page 38].
Procedure
Create New Object/Open Object

You can navigate directly to already assigned objects anywhere where you can assign objects in your loss and
treaty data. In some cases, you can also create new objects here.
To create an object independent of any other data, start transaction /MSG/H_OBJ01 (in the initial menu under
Risk Manager [or Basic System] Object Manager Create/Edit/Display Object ).
Create New Object Group
You create an object group in the same way as an object using transaction /MSG/H_OBJ01. Set the Object
Group checkbox before you choose Create. If you set this checkbox, you can assign subobjects to this object
later.
Add Objects to an Object Group or Remove Objects From an Object Group
Note that the period of validity of the object group must cover the entire period of validity of the subobject.
You can also assign a different object group as a subobject to an object group and define an object hierarchy.
However, circular references are not allowed.
● In the object group: Open the object group and switch to the Assigned Objects tab page. A table of objects
appears that match the selection criteria you selected for the object group.
● In the subobject: Enter or delete the number of the object group on the Object Definition tab page.
Display Use of an Object
Open the object as described above and switch to the Participation, Policy Group Header, or Policies tab page.
Manage Additional Information
Functions for creating, displaying, or deleting the additional information for an object and information about a
period that is an object are available only in NWBC applications.
Release Object for Use in Policies and Treaties
If you have assigned a status that allows posting to the object you can assign this object in participations,
policy groups, policies, policy sections, coverages, values insured, and premiums. The system does not check
the status when you assign an object to a loss.
Delete Object
You can delete objects in the overview of objects in transaction /MSG/H_OBJ01.
An object can be deleted only if:
● The object must not be an object group to which another object has been assigned
● The object is not being used in any treaty or policy section and in any loss
Copy Object
For more information, see Copying Objects [page 41].

4.3.1.1.1.1 Copying Objects
Prerequisites
You can copy objects only if the following conditions have been met:
● The object you want to copy exists in the system.

● The object you want to copy is not being edited.
● You are authorized to edit objects.
Context
You use this procedure to copy an object. Once you have copied an object, you can change the new object and
this saves you time when creating similar objects.
 Note
The following description relates to the copying of objects during classical object processing and if objects
are managed using Object Instance Floorplan (OIF). For more information about copying objects if they are
managed using overview pages (OVP), see Copying Objects (OVP) [page 46].
Procedure
1. Call the copy function.
You find the corresponding transactions on the SAP Easy Access screen under User Menu FS-RI:
Reinsurance Risk Manager Contract Manager .
On the initial screen, specify how you want to use the copy function.
You can select the following functions under Selection:

○ Copy Policy
○ Copy Object
2. Select Copy Object.
3. Enter the following data in the middle section of the screen:
○ Source Object (ID of the object to be copied; required)
○ Target Object (ID to be assigned to the copied object; optional)
○ Name of Target Object (you can also enter the name after the object has been copied; optional)
4. You can also select the following:
○ Copy Object/Group Assignment

○ Copy Extension Service Data
 Note
If you select Copy Object/Group Assignment, the system also copies the object references defined
on the Assigned Objects tab page. If you want to make several copies with the same selection
criteria, choose Save As Variant. To use this variant when you create the next copy, choose Get
Variant.
5. Choose Execute.
Results
1. The object has been copied.
 Caution
The system does not copy the object's assignments to policies, policy sections, coverages, values
insured, and premiums.
2. The system displays a success message. This message shows the number of entities copied and the IDs of
the source object and target object.
4.3.1.1.2 Object Processing
You can use SAP Reinsurance Management for SAP S/4HANA (FS-RI) to create, edit, display, copy, and delete
objects.
The system supports you as follows:
● You can use an object management [page 42] application that is based on a floorplan for overview pages
(OVP) using generic interface building blocks (GUIBBs).
Alternatively, you can use corresponding applications in SAP NetWeaver Business Client [page 46] (NWBC
applications) that are based on Object Instance Floorplan (OIF) and do not support the copying of objects.
4.3.1.1.2.1 Object Management with Overview Pages (OVP)
Use
The management of objects using overview pages supports you during the creation, editing, display, and
deletion of objects.
You access the new object applications by starting the Object Management application in SAP NetWeaver
Business Client (NWBC) under FS-RI 700_01 Loss Processing Object Object Management .

For more information about the structure of the user interface and the functions for controlling NWBC
applications, see Structure of the User Interface [page 778].
Prerequisites
● Before you can use the SAP NWBC object applications, you have to activate the corresponding HTTP
services for SAP Reinsurance Management for SAP S/4HANA in parallel to the services for operating SAP
NWBC. You use transaction SICF to do this.
● You have assigned the new applications for object management to the corresponding PFCG roles.
 Note
For more information about configuring SAP NWBC and the Web Dynpro applications, see Configuring Web
Dynpro Applications and SAP NetWeaver Business Client [page 778].
Features
The management of objects using overview pages comprises the following steps. The process flow is described
in the following sections:
● Creating and Editing Objects and Object Groups [page 43]

● Deleting Objects [page 45]
● Copying Objects (OVP) [page 46]
4.3.1.1.2.1.1 Creating and Editing Objects and Object Groups
Use
You use this function to create new objects and object groups or to edit existing objects and object groups.
The structure of the navigation tree when objects are managed using overview pages (OVP) comprises the
following pages:
● Basic Data
● Object Assignment
Procedure
How to Call Object Management

1. Start the Object Management application under FS-RI 700_01 Web Dynpro Loss Processing Object
Object Management .
2. On the search screen [page 778] under Results List, choose the New pushbutton.
3. The Basic Data page appears. You can create the new object here.
Basic Data
1. Basic data
The following areas are available on the Basic Data page:
○ Basic Data
○ Business Partner
○ Natural Persons
○ Responsibilities
○ External References
○ Additional Data
○ Change Data
○ Attachments
○ Notes
2. Fill the required entry fields:
○ Under Basic Data: Object Name, Object Category, and Status
When you assign a subobject to an object, the system sets the Object Group checkbox.
○ Under Responsibilities: Business Partner ID
You can use the object category to specify which areas are to be displayed.
You can define the object category in Customizing for FS-RI Risk Manager (Non-Life) under Object
Management Edit Object Categories .
For more information about the object category, see the corresponding system documentation.
Default Settings
When you create a new object the system fills the following fields:
○ Company Code: the company code defined for the system environment
○ Start Date: current date
○ End Date: “31.12.9999”
○ Business Partner Role: depends on the respective Customizing setting
3. Choose the Save pushbutton.
Object Assignment
In the Object Management application you can assign several subobjects to an object.
This is permitted only if the object covers the area and the validity period of the subobject.
Proceed as follows:
1. Select an object from the search screen in the Object Management application.
2. On the Loss Objects page under Object Assignment, choose the New pushbutton.
3. In the Object ID field, enter the corresponding object ID. In the Search: ID dialog box you can enter different
search criteria to find specific objects.
4. Choose the Save pushbutton to save the corresponding object assignment.
 Note
You can also enter and edit responsibilities, external references, and attachments and notes.

For more information, see Responsibilities [page 658], External References [page 658], and Attachments
and Notes [page 659].
Result
You have created the new object or object group and you can edit this as follows.
Edit Object
● All areas: choose the Edit pushbutton in the toolbar.

● Individual areas: choose the Edit pushbutton in the corresponding area.
If the status of the object is “Posting Allowed”, entries cannot be made in the fields at basic data level.
Edit Object Group
1. Under Object Assignment, select the name of the subobject.

2. The Object Management application opens with the Basic Data page. You can edit the subobject here.
4.3.1.1.2.1.2 Deleting Objects
Use
You can use this function to delete an object that is managed using overview pages.
Procedure
Proceed as follows:
1. Start the Object Management application under FS-RI 700_01 Loss Processing Object Object
Management .
2. Select an object from the search screen.
3. Highlight the corresponding row on the Object Assignment page and choose the Delete pushbutton in the
Actions column.
4. If you want to delete several objects at the same time, highlight these objects on the Object Assignment
page and choose the Delete pushbutton in the Object Assignment screen area. A dialog box appears in
which you can confirm or cancel the deletion of the objects.

4.3.1.1.2.1.3 Copying Objects (OVP)
Use
You can use this function to copy an object that is managed using overview pages.
Procedure
Proceed as follows:
1. Start the Object Management application in NWBC under FS-RI 700_01 Loss Processing Object
Object Management .
2. Select an object from the search screen.
3. Highlight an object in the Results List table.
4. In the table toolbar choose the Copy pushbutton to copy the required object.
Result
You have copied the object.
The system assigns a different ID to the copied object and sets its status to “COPY”.
4.3.1.1.2.2 Object Management with Object Instance

Floorplan (OIF)
Use
The following describes the procedures for editing objects, object groups, and object relationships using Object
Instance Floorplan (OIF).
 Caution
Note the following:
● NWBC is not part of the basic license for SAP Reinsurance Management. Before you can use the NWBC
applications, you have to configure NWBC [page 778].
● For technical reasons, the system regards an object as an object group if the Object Group checkbox
has been set. This means that you can assign subobjects to this object. For this reason, you can often
use the same initial screen to create an object group as you use to create an object.
For more information about the structure and use of objects, see Object [page 38].

Procedure
Create New Object/Open Object
You have the following options:
● Use the application WDY_APPLICATION (Object Management).

● Create the object directly from the loss. To do this, switch to the Loss tab page and to the Object
Assignment screen.
Create New Object Group
● Create an object as described above and set the Object Group checkbox on the Object tab page.
● Assign a subobject to the object on the Subobjects tab page. The Object Group checkbox is then set
automatically.
Add Objects to an Object Group or Remove Objects From an Object Group
● In the object group: Open the object group and switch to the Assigned Objects tab page. Here you can use
the New pushbutton to assign new subobjects or remove assigned objects from the assignment table.
● In the subobject: Enter the number of the object group on the Object tab page.
Enter and Delete Additional Information
On the Additional Information tab page in the object you can add and delete file attachments, notes, and links
to the Internet/Intranet.
Enter Information About Natural Persons as Insurance Objects
When you manage objects using OIF, you can enter information about natural persons for the corresponding
object category. The available personal data relates to date of birth, date of death, and gender.
Release Object for Use in Policies and Treaties
If you have assigned a status that allows posting to the object you can assign this object in participations,
policy groups, policies, policy sections, coverages, values insured, and premiums. The system does not check
the status when you assign an object to a loss.
Delete Object
You can delete objects in the overview of objects when you manage objects in OIF.
An object can be deleted only if:
● The object must not be an object group to which another object has been assigned
● The object is not being used in any treaty or policy section and in any loss
Copy Object
For more information, see Copying Objects [page 41].

4.3.1.2 Original Policy
Definition
The original policy maps the business between the policyholder and the primary insurer.
Use
The data in the original policy is the basis for your own business, regardless of whether you are the primary
insurer, the reinsurer, or a retrocessionaire at any point in the reinsurance chain. You map your business as a
participation in one or more policy sections of the original policy (or as a participation in the cession of another
participation that itself participates directly or indirectly in the original policy). This means that wherever you
are in the participation chain, you must always begin by entering the liability data for the original policy.
Structure
The policy data that is relevant for the liability is stored in the policy sections [page 49] or under the values
insured.
At policy level you save only the data relating to the participating partners [page 48] and general information
about the policy type and validity period as original policy data.
Integration
When you define participations in the original risk, you always reference policy sections and cession groups,
and never the policy itself. However, the policy acts as the “container” for the policy sections when cession
groups are created.
For more information, see Cession Group Creation [page 93].
4.3.1.2.1 Partner Involved
On the Partners Involved tab page you enter the business partners that are involved in the policy in some way
during the respective period. If you set the Relevant for Accounting checkbox for a broker, you can use this
broker in the account. In addition, the system displays the partners involved in the policy header (for
information only).
 Note
You must ensure that the business partners you need have already been created in the system and
assigned to the corresponding role.

You can enter or change your business partner data under FS-RI: Reinsurance Business Partner Edit
Business Partner .
4.3.1.2.2 Policy Section
Definition
Policy sections structure the scope covered by the policy. Each policy can have several policy sections, and
each of these policy sections can have several coverages.
Structure
Policy sections contain data that maps the original business, as well as assignments to groups and
participations.
 Tip
We recommend that you first enter the data for the original business and initially ignore the tab pages for
assigning groups and participations. You should assign the groups and participations only after you have
entered all the details for the original business.
Data for the Original Business
Tab Page: “Policy Section Data”
The “Policy Section Data” tab page also contains general data, such as the main structural characteristics
[page 131], values and their value types [page 59], and the valuation date for currency translation. You can
either enter values directly on this screen or have the coverages and values insured calculated by the liability
aggregation function.
Other Tab Pages
For more information about the data for the original business, see the relevant subsections.
Data for Groups and Accumulations
For more information about how to create and assign policy section groups and accumulations, see Grouping
of Original Business [page 79].
Data for Participations
For more information about how to create and assign participations, see Definition of Participations [page
87].

Integration
Policy section groups form the basis for defining participations in a risk.
 Note
In Customizing for FS-RI Reinsurance under FS-RI Risk Manager (Non-Life) Default Values for New
Objects Set Default Values at Policy Level , you can define default values for all the fields based on the
policy section category entered.
4.3.1.2.2.1 Subcoverage
Definition
The coverage relates to a policy section and connects values insured, premiums, and objects that belong
together.
It comprises:
● The type of risk being insured (such as liability coverage or object coverage)
● The value insured in case of loss (such as debris removal costs)
● The type of premium to be paid for the value insured (such as a one-time premium)
● The insured object (such as power station, natural person)
● The types of premium assigned to the defined values insured
Use
You can enter as many coverages as you want for a policy section. A coverage does not have its own validity
period, but is instead linked to the validity periods for the assigned values insured, premiums, and objects.
 Note
All the coverage data (premium, value insured, object) is stored for information purposes only.
Creating a Coverage
1. To enter a coverage, switch to the Policy Section Headers tab page on the Change Policy screen.
2. Select a policy section by double-clicking the corresponding row in the overview table. The Change Policy
screen appears, and the Policy Section Data tab page is selected.
3. Switch to the Coverages tab page.
4. An overview of all the existing coverages appears. To create a new coverage, choose Create Coverage. A
dialog box appears in which you can enter a name for the coverage and the coverage category. Choose
Enter.
5. The screen for the coverage level appears with the tab pages Coverages, Value Insured Journals, Premium
Journals, Val.Ins./Premium Assignment, Objects, and Extension Service.

6. You can then enter the following for a coverage by choosing the corresponding functions:
○ Benefit [page 52]
○ Premium [page 56]
○ Object [page 38]
7. The Value Insured Journals, Premium Journals, and Objects tab page each give you an overview of the
respective entries that have been created.
Integration
The entry of a coverage for a policy section is optional. You can enter several coverages for a given policy
section, whereby a coverage is always assigned to a single policy section.
For each coverage, you must enter at least a value insured, premium, or object. You can assign more than one
object to a coverage. An object assigned to a given coverage may also be assigned to other coverages and to
other policy sections, which may belong to different policies.
If you enter a value insured for a coverage, it only applies to this coverage. You can enter several values insured
for a coverage.
If you enter a premium for a coverage, it applies only to this coverage.
You can enter several premiums for a coverage. You can assign the premiums and values insured you have
entered to each other on the Val.Ins./Premium Assignment tab page.
 Note
You can assign only one value insured to each premium.
4.3.1.2.2.1.1 Adding and Deleting Objects in a Coverage
Use
On the Objects tab page you can add an object [page 38] to a coverage. You can also change or delete the
object coverage.
Prerequisites
If you are using an existing object, the validity period of this object must cover the validity period of the
coverage (start of coverage, end of coverage).

Procedure
1. To add an existing object to a coverage, switch to the Objects tab page on the FS-RI: RM (Non-Life) –
Change Coverage screen. On this screen you can enter the number of an object in the Object column.
2. After you have entered the Start of Coverage and End of Coverage, save your entries. You have now
assigned the object to the coverage. You can also create a new object from here.
3. You can change the object coverage on the same screen by changing the attributes in the table and saving
your entries. To delete an object from the coverage, select the relevant row and choose Delete.
4. Then choose Save.
 Note
The period defined by the Start of Coverage and End of Coverage must fall within the validity period of the
related policy section (start of policy section, end of policy section).
4.3.1.2.2.1.2 Value Insured
Definition
The value insured is the amount the insurer is contractually obliged to pay in the case of a claim.
The main attributes of the value insured are as follows:
● Type of value insured (such as debris removal costs)

● Valuation data (currency, exchange rate, valuation date)
● Value insured data (sunset period, rank, index type, start of index period, start of value insured period)
● Values (you can enter several values and corresponding values types in a table)
● External reference (ID of the value type in operational or partner systems)
Use
Creating a Value Insured
You first call the coverage for which you want to create a value insured. On the FS-RI: RM (Non-Life) - Change
Policy screen, switch to the Coverage tab page. Double-click the coverage for which you want to create a value
insured.
Choose Value Insured. The Create Value Insured dialog box appears.
Here you enter the key identifying attributes of the value insured.
Attributes
● Value insured (user-defined name)

● Type of value insured (such as debris removal costs), value insured valid from/to
● Valuation date (required for currency translation)

● Underwriting date
● Status
● Reason for change
● Currency
Choose Continue. The screen for the Value Insured tab page appears. You can then make your entries in the
sections Value Insured Data, Statistics/Values, and References.
Value Insured Data
You can enter the following information in the value insured data:
● Sunset period
● Start of value insured after
● Relevant for liability
● Rank
● Index type
● Start of index period
● Extension Service
● Exclusion of values insured
Statistics/Values
You can enter several values in the Statistics/Values section. However, a value type may be used only once. You
first enter the desired value type and choose Continue. You can then enter the following:
● Amount (% or absolute amount, depending on the value type)

● Currency and exchange rate type
● Indicate whether the value type is relevant for liability aggregation
● Validity period
In the References section you can enter the ID used in operational or partner systems.
Changing a Value Insured
On the FS-RI: RM (Non-Life) - Change Policy screen, switch to the Coverage tab page. Double-click the coverage
for which you want to create a value insured. On the next screen, switch to the Value Insured Journals tab page.
Select the value insured you want to change.
Deleting a Value Insured
To delete a value insured, navigate to the value insured as described under “Changing a Value Insured”. In the
overview of values insured, select the row for the value insured you want to delete and choose the Delete
pushbutton.
Structure
The value types and values are key entries for the values insured.
The statistical value types are transferred from the corresponding operational value types and propagated
upwards to the higher levels.

The sequence of the levels from bottom to top is: value insured – coverage – policy section – policy –
accumulation. In Customizing you can define the levels at which operational value types can be entered based
on your own requirements.
The Gross Liability is the statistical value type upon which further functions are based. It is always taken from
the operational value type defined as the liability calculation base. You define the liability calculation base for
each class of business in Customizing. Unlike the values for other operational value types, you can only enter
the value for the liability calculation base at value insured and policy section levels. If you enter the value at
both levels, and the Relevant for Aggregation checkbox is also set at both levels, the system uses the values
entered at value insured level.
4.3.1.2.2.1.2.1 Copying Values Insured
Prerequisites
You can copy the value insured if the following conditions have been met:
● The policy is not being edited.

● The status of the policy does not allow posting and is not reversed.
● You are authorized to edit the policy.
Context
You can use this procedure to copy a value insured within a policy.
Procedure
1. Call the copy function on the SAP Easy Access screen under User Menu FS-RI: Reinsurance Risk
Manager Contract Manager Copy Original Policy/Objects .
On the initial screen, specify how you want to use the copy function. In the upper section of the screen you
can select Copy Policy or Copy Object.
2. Select Copy Policy.
In the middle section of the screen you can specify which parts of the policy you want to copy. You can
select the following:
○ Copy Policy
○ Copy Policy Section
○ Copy Value Insured

○ Copy Premium
3. Select Copy Value Insured.
The Copy Value Insured selection screen appears at the bottom of the screen. Here you enter the details for
the value insured to be copied.
4. Enter the values for the source value insured in the following fields:
○ Source Policy (ID of the source policy; required)
○ Source Policy Section (ID of the source policy section; required)
○ Source Coverage (ID of the coverage to be copied; required)
○ Source Value Insured (ID of the value insured to be copied; required)
5. Enter the values for the target value insured in the following fields:
○ Target Value Insured (enter an ID that has not yet been used for a value insured belonging to the
specified coverage)
○ Name of Value Insured (optional)
6. Choose Execute.
An interim screen with selection options appears. The values that are copied by default are flagged.
7. If necessary, modify the selection and choose Check.
 Note
After you choose Check, check to see if the system has adjusted your selection. The following types of
adjustment can occur: For example, you select the Value Insured to be copied, but not the Value Insured
Header. In this case, the system removes the selection for the value insured, since this cannot be
copied without the header.
If you want to make several copies with the same selection criteria, choose Save As Variant. To use this
variant when you create the next copy, choose Get Variant.
8. Choose Execute.
Results
1. The value insured has been copied.

2. The system displays a success message.
The message lists the source policy IDs, the source policy section, the source coverage, the source value
insured, and the target value insured, as well as the number of copied subentities (value insured header,
values).

4.3.1.2.2.1.3 Premium
Definition
In Contract Manager you can enter premiums for information purposes on the Premium tab page. These are
not the premiums that have actually been paid or are due to be paid. The actual premiums are entered
manually in the account, or calculated by the system during the automatic posting run for expected premiums.
Use
Creating a Premium
You can enter premiums for an existing coverage.
1. On the FS-RI: RM (Non-Life) - Change Policy screen, switch to the Coverage tab page. Double-click the
coverage for which you want to enter a premium. On the next screen, choose Premium.
2. You then enter the header data in the dialog box:
○ Premium (user-defined short text) and a long text
○ Premium category
○ Premium start and end date
○ Underwriting date
○ Status
○ Reason for change
○ Currency and exchange rate type
Choose Continue. A new screen appears.
3. The header section contains the following data fields:
○ Premium Category
○ Accounting Period
○ Currency
○ Exchange Rate Type
○ Valuation Date
Here you can enter all the data for the premium period or change existing premium data.
The system uses the valuation date as the exchange rate date if currencies have to be translated. If you
leave this field blank, the system uses the start date of the policy section period for which the coverage
was created.
4. In the Statistics/Values section, you enter a value type in the first column and choose Continue. The
system enters the long text for the value type and you can enter values in the following fields:
○ Value
○ Value Fixed
○ Exchange Rate (*) for value types
○ Exchange Rate Type (*)
○ Dimension
(*): You can enter values in this field only if the value type is an amount.

The dimension is the factor by which the value is multiplied to calculate the effective value. The default
entry is “1”. This field is important if the actual value exceeds the number of digits available for the value
field.
Value Fixed: If you have entered several value types that depend on each other, set the Value Fixed
checkbox for those values that you do not want to be changed by calculations.
5. The Premium Data section contains the following fields:
○ Extension Service
○ Adjustment
The Extension Service is the Extension Service ID and describes a technical view of additional customer-
specific fields that have been created in the system. If you select this field, the system adapts the fixed
premiums whenever you change the validity period to reflect the new period. Otherwise, the fixed premium
remains constant.
6. In the References section you can specify external reference IDs for the premium (such as the premium ID
of the cedent). You first enter a valid value in the first column (external reference category). You then
choose Continue, fill in the required fields, and save your entries.
Changing a Premium
1. On the FS-RI: RM (Non-Life) – Change Policy screen, switch to the Coverage tab page and select a coverage.
2. Now switch to the Premium Journals tab page and select a premium. If you have already entered several
premium periods, you may have to select the correct premium period.
3. You can then change the entries for the fields that are ready for input and save the changes. For more
information about the meaning of the fields, see “Creating a Premium”.
Displaying a Premium
To display a premium, navigate to the premium as described under “Changing a Premium”.
4.3.1.2.2.1.3.1 Copying Premiums
Prerequisites
You can copy the premium if the following conditions have been met:

Context
You can use this procedure to copy a premium within a policy.

Procedure
○ Copy Policy
○ Copy Premium
3. Select Copy Premium.
The Copy Premium selection screen appears at the bottom of the screen. Here you enter the details for the
premium to be copied.
4. Enter the values for the source premium in the following fields:
○ Source Coverage (ID of the coverage to be copied; required)
○ Source Premium (ID of the premium to be copied; required)
5. Enter the values for the target premium in the following fields:
○ Target Premium (enter an ID that has not yet been used for a premium belonging to the specified
coverage)
○ Name of premium (optional)
6. Choose Execute.
 Note
After you choose Check, check to see if the system has adjusted your selection. The premium can only
be copied if the Premium Header and Premium Value fields are both selected. You can decide whether
to include the subentity External Reference.
8. Choose Execute.

Results
1. The premium has been copied.

The message lists the source policy IDs, the source policy section, the source coverage, the source
premium, and the target premium, as well as the number of copied subentities (premium header,
premiums).
4.3.1.2.2.1.4 Assigning Premiums to Values Insured
Procedure
1. On the Coverage screen, choose the Val.Ins./Premium Assignment tab page. This screen contains three
tables. The value insured data is on the left and the premium data is on the right.
2. To assign a premium to a value insured, select a value insured and use the arrow key to enter it in the next
free row of the Assignment table in the middle of the screen. Then select this entry. In the table on the
right, select the premium you want to assign to the selected value insured, and transfer it to the table using
the left arrow key.
3. You can make further assignments in the same way. You cannot assign two values insured to one premium.
Each premium can be assigned to only one value insured.
4.3.1.2.2.2 Value Types
Definition
The value type defines the meaning of the value, such as “sum insured” or “maximum liability”.
Statistical Value Type
Statistical value types are not entered by the user. These are the values calculated by the liability aggregation
function.
Operational Value Type
You define operational value types in Customizing for FS-RI Reinsurance under Risk Manager (Non-Life)
General Settings Define Value Types .

Use
You use value types to classify the values stored and to define the relevant values for liability aggregation. You
can enter value types at the following levels:
● Premium journal
● Value insured journal
● Coverage
● Policy section
● Participation
Calculation of Value Types
Operational Value Types
You can enter the values for the operational value types manually or have them calculated automatically by the
system. In the latter case, one or more calculation rules must be defined for this value type.
If several calculation rules have been defined for a value type, the system applies all the calculation rules for
which values are available or can be calculated.
Each calculation rule must produce the same result when it is used. Otherwise, the system returns the error
message “Different results for the value type XY”.
With the introduction of participations, calculation rules can incorporate value types from different levels. This
means that the calculation may relate to value types from the original policy section or value types from the
preceding participation.
If the Value Fixed checkbox has been set for a value type, the value is not calculated automatically.
You define the calculation rules for value types in external Customizing for Risk Manager Non-Life under
Statistical Value Types
The statistical value types are calculated by the liability aggregation [page 75] function. The system displays
only statistical values for which the date in the As Per field falls within the corresponding period. If the As Per
date is before the first period for statistical value types, the system displays the value types for the first period.
If the As Per date is after the last period, it displays the value types for the last period.
Circular References and Fixed Value Types
When value types are calculated, the system automatically detects circular references.
A circular reference exists when two of the value types refer to each other in their respective calculation rules.
If the system finds a circular reference, it prompts you to correct it. In this case, you must decide which value
type you want the system to calculate. All the other value types are flagged as "Fixed".
Value Types During Liability Aggregation
Relevant Value Types For Each Class of Business
The liability aggregation function takes the liability amounts from lower levels and calculates the total liabilities
at higher levels. The values relevant as “liability amounts” depend on the class of business. You define the
relevant value types for a given class of business in the Customizing activity Edit Classes of Business.
Statistical Value Types

The statistical value type is the value type the system calculates on the basis of the corresponding operational
value types and uses for liability aggregation. You cannot enter these value types manually. You define the
operational value types to be used as the basis for statistical value types in the Customizing activities for value
types.
Dimension of Value Types
The actual value of a value type with a given dimension is calculated by multiplying the value for the value type
by the value in the “Dimension” field.
Default Entries for Value Types When Creating New Objects
When you create a new policy, policy section, coverage, value insured, premium, or participation, the system
enters the defined default values for all value types on the overview screen. You define these default values in
Customizing for Risk Manager and you specify the level (such as “premium”) and category (such as “one-time
premium”). You cannot enter statistical value types.
You define the default values for value types in external Customizing for Risk Manager Non-Life under
4.3.1.2.2.3 Class Model with Risk Classes
Definition
You can use class models to differentiate risks according to your own criteria.
For example, you could divide your life insurance portfolio into smokers and non-smokers, or classify your fire
insurance business on the basis of additional safety measures in excess of those required by law. In these
cases, “smoking habits” and “safety standards” would be class models. The attributes “smoker”, “non-
smoker”, “sprinkler system” and “no sprinkler system” would be the corresponding risk classes.
Use
If you assign the risks you assume to risk classes, you can reinsure each risk class differently. For more
information, see Risk Classes for Cession Calculation [page 99].
Structure
You define class models in external Customizing for Basic System under Interfaces RM Connection RIP
Settings .

Example
For an example of the process, see Example: Defining and Maintaining Class Models (Optional) [page 179].
4.3.1.2.2.3.1 Creating Extension Services for Objects
Context
If you want to classify objects in detail and create cessions on the basis of this object classification, you must
define the additional information in the FS-RI system by creating an Extension Service for the object table. For
example, the object "spaceship" could have different classes for the "year of construction" and the "number of
seats".
To store this special “spaceship” information, you first have to create or change an Extension Service for the
object table, and then create an Extension Service view specifically for the fields that are relevant for
spaceships.
Procedure
1. In external Customizing for Basic System, choose Extension Service Extension Service
Administration .
2. On the left of the screen, double-click the application for which you want to create an extension. In this
example, the application is Object Manager FS-RI-RM-OBJ. On the right you see the extendable table for
the selected application. In this example, there is only one object table /MSG/HOBJECT.
3. Select the table to be extended by double-clicking it. You can now change an existing extension (double-
click) or create a new extension.
 Note
You can create a maximum of five extensions per table. (If you have already created five extensions, you
can still create additional fields.)
 Caution
You should decide beforehand which fields you want to add to the extension. Once you have added a
field using the Change Field Selection pushbutton, you can no longer delete it from the extension.
4. Choose Maintain Fields to create the fields you require.

5. Save your entries, and generate the table extension.
6. You can now create a view of the extension by selecting the extension and choosing Views. In the
"spaceship" example, the view SPACE could be applied to the extension /MSG/EC_OBJECT.

7. In Object Manager, you could then choose the view SPACE as an Extension Service. You would enter the
values for the corresponding fields (such as year of construction, seats, country, and usage) on the
Extension Service tab page.
4.3.1.2.2.3.2 Creating Extension Services for Cession

Calculation
Prerequisites
You have carried out the steps outlined in Creating Extension Services for Objects [page 62].
Context
Once you have created the extension for the object table, you must define the classification criteria to be used
by the Risk Manager cession calculation function to assign objects. To transfer the criteria to the cession
calculation, you must create an extension for the cession calculation table. You also do this using the Extension
Service.
Procedure
1. In Customizing for FS-RI Reinsurance choose Basic System Extension Service Extension Service
Administration .
2. On the left of the screen, double-click the application “FS-RI-RM-MK” (cession calculation). On the right of
the screen you then see a table control containing all the extendable tables for this application.
3. Double-click the table entry /MSG/RRVOKMOD (RIP: class model). The next screen shows all the extensions
that have been created for table /MSG/RRVOKMOD.
4. You can now create a new extension or add fields to an existing extension. The basic procedure is the same
as for creating extensions for objects (see Creating Extension Services for Objects [page 62]), and involves
creating fields, selecting fields, activating the Extension Service, and creating views.
However, when you select and maintain the extension fields and corresponding view(s), you must take the
following factors into account:
○ The names of the fields in the extension for cession calculation must begin with the letter
combinations below:
○ CT_ = unique fields contents
○ OP_ = operator for unique field checks (=, <, >, <>)
○ CL_ = lowest value for an interval field

○ CH_ = highest value for an interval field
○ OL_ = operator for the lowest value for an interval
○ OH_ = operator for the highest value for an interval
○ You must ensure that an operator field is defined for every individual value field (the same applies for
interval fields).
○ Risk Manager makes the assignment on the basis of the field name that follows the prefix. For example,
CT_SEATS would belong to OP_SEATS. In the case of intervals, this convention applies to all four
interval fields (two value fields for the limits and two operator fields).
○ The Class field must be included in every view for the cession calculation extension.
○ The names of the fields in the view for the cession calculation extension do not have to correspond to
the names of the fields in the object extension. The fields are assigned to each other in a separate step
(see Assigning Extension Services for Objects and Cession Calculation [page 64]).
○ You do not have to use all the fields created in the Extension Service for the objects as classification
criteria for the cession calculation.
4.3.1.2.2.3.3 Assigning Extension Services for Objects and

Cession Calculation
Use
The cession calculation function must know which fields of the object Extension Service correspond to the
fields of the cession calculation Extension Service you have just created. You define this relationship in an
assignment table in Customizing.
 Note
You only need to perform this step if the fields in the extension for the object table differ from those in the
extension for cession calculation.
Prerequisites
Before you can make the assignments, you must make a setting to let Risk Manager know which cession
calculation extension tables can be referenced in the assignment table. You do this in Customizing for Basic
System under Extension Service Edit Defaults for Extension Service Tables . If this table already contains
the extension to the object table created previously, you do not need to create any new entries. Otherwise, you
must add the extension table you created to extend the object table.
Procedure
You make the actual assignment in Customizing for FS-RI Reinsurance under Basic System Interfaces
RM Connection RIP Settings Edit RIP Defaults for Cession Calculation Criteria .

1. Select the table you want to link to (this is usually the table of object extensions), and then select the
relevant fields.
2. Assign the corresponding fields from the cession calculation extension to these fields. You must also define
the procedure for merging different values. This is necessary, for example, when a cession group contains
several objects, and the values in the respective Extension Services have to be consolidated.
Example
In the spaceship example, you would select the extension table for the object table /MSG/EC_OBJECT and its
fields Construction Year and Seats. You would assign these values to the fields CT_BAUJAHR and CT_SITZE.
4.3.1.2.2.3.4 Creating Class Models
Use
After you have defined the individual fields to be used for allocating the business into different classes, you
then create a class model. The class model stores the conditions and upper and lower limits for assignment to
a certain class.
Prerequisites
You have already completed the following activities:
1. Creating Extension Services for Objects [page 62]

2. Creating Extension Services for Cession Calculation [page 63]
3. Assigning Extension Services for Objects and Cession Calculation [page 64]
Procedure
You create class models in external Customizing for FS-RI Reinsurance under Basic System Interfaces
RM Connection RIP Settings Define RIP Class Model . In this Customizing activity, you can see all the class
models that have been created to date.
1. To create a new class model, choose New Entries. Enter the company code, number and name of the class
model, and the Extension Service containing the fields to be used for the classification. This is the
extension of the cession calculation table you created in the step Creating Extension Services for Cession
Calculation [page 63].
2. Create the various classes to which you want the model to make allocations, and assign them to the class
model. To create the classes, double-click the Classes folder in the tree on the left of the screen.

3. A window containing all the existing classes then appears on the right of the screen. If the classes you
require are not available, you can create them using the New Entries pushbutton.
4. Once you have created all the classes you require, you must assign them to the relevant class model. To do
this, double-click the Class Model folder. The system then displays all the existing class models on the right
of the screen (including the one you created previously).
5. Select the model for which you want to enter classes and double-click the Class Assignment folder to go
the assignment screen. Here you can assign the class model to the class you have just created.
Example
In the spaceship example, the class model has the ID SPAC and the short text SPACE. Two classes have been
assigned to this model (SP1 and SP2). The model therefore offers two “categories” – one for high risks, and
one for low risks.
4.3.1.2.2.3.5 Defining and Editing Class Models
Use
After you have created the class model, the cession calculation function in Risk Manager can recognize the
categories to which the risks can be allocated. However, it still has no indication of when a risk belongs in the
first category (SP1) or the second category (SP2). In the next step, you therefore have to specify the allocation
conditions.
Prerequisites
1. Creating Extension Services for Objects [page 62]

2. Creating Extension Services for Cession Calculation [page 63]
3. Assigning Extension Services for Objects and Cession Calculation [page 64]
4. Creating Class Models [page 65]
Procedure
You define the criteria you want the cession calculation function to use for allocation in external Customizing
for Basic System under Interfaces RM Connection RIP Settings Edit RIP Class Model .
1. On the screen containing the existing class models, select the model for which you want to define the
conditions. On the next screen, you can assign upper and lower limits for the individual classes. The
columns in this table control contain the individual fields of the cession calculation extension that you
assigned to the class model in the step Creating Class Models [page 65].

2. Use the data and operator fields to define the various conditions to be applied by the cession calculation
function to allocate the risk to the relevant class.
 Caution
In the Class column, you can enter only classes that have been defined in the class model you are currently
processing.
Example
In the spaceship example, you can define the criteria for the class model SPAC created earlier. The risks can be
allocated according to the criteria Construction Year and Seats.
4.3.1.2.2.3.6 Transporting Class Models
Prerequisites
All the objects you want to transport have been created.
Context
You follow this procedure to transport a class model defined in Customizing to a different client or machine.
Procedure
1. In external Customizing for Basic System, choose Interfaces RM Connection RIP Settings Edit RIP
Class Model . Choose the Transport pushbutton. The system creates a new Customizing transport
request containing the class model.
2. Contact your SAP system administrator for information about how to import this transport to the target
system.

4.3.1.2.2.3.7 Creating Extensions for Cession Groups
Use
To enable the cession calculation function to use the fields defined for the class model and the reinsurance
program, and to link these fields with individual cession groups, you must create a special extension for the
cession group to incorporate the class model fields.
Procedure
1. In Customizing for FS-RI Reinsurance choose Basic System Extension Service Extension Service
Administration .
2. For more information about the basic procedure for creating extensions, see Creating Extension Services
for Objects [page 62]. To create extensions for cession groups, you select the application “FS-RI-RM-GRP
(Cession Group)” in the navigation tree on the left-hand side of the screen. You then select the table /MSG/
NGRP (groups) as the table to be extended on the right-hand side of the screen.
3. On the next screen, you either create a new extension table, or extend an existing table. The procedure is
the same as in previous steps (Change Field Selection, Activate, and so on).
 Note
Ensure that all the fields used in the class model are specified in the Extension Service (except for the OP_
fields and the Class field). All C*_ fields that are to be used for cession calculation and are used in the class
model must also be defined in the new Extension Service.
Once you have created the Extension Service and fields, you must create a view of the fields to be used. This
procedure is also described in earlier steps.
Result
The Risk Manager cession calculation function can now find and assign the corresponding Extension Services.

4.3.1.2.2.4 Editing Policy Sections
Use
The following functions are available for editing policy sections:
Features
Function How to Call the Function Important Information
Create new policy section ● Via the initial screen

● From within the policy, using the
pushbutton.
Create new policy section period for ex If several policy section periods exist for
From within the policy, using the
isting policy section a policy section header, no entries can
pushbutton.
be made in the fields for the policy sec
tion category, class of business, line of
business, area, and business type in the
policy section header.
Check policy section Choose the Check pushbutton at policy

section level.
Delete policy section Go to the Policy Section Headers tab

page at policy level. Select the policy
section you want to delete and choose
4.3.1.2.2.5 Copying Policy Sections
Prerequisites
You can copy the policy section header if the following conditions have been met:
● The policy in which you want to copy the policy section is not being edited.

Context
You can use this procedure to copy a policy section. The system copies the policy section header and the
assigned policy section (which may contain several policy section periods), as well as all the coverages defined
for the policy section with the related values insured and premiums. The system assigns a new policy section
number to the copied policy section header. The periods are not affected by the copy process.
Procedure
○ Copy Policy
○ Copy Premium
3. Select Copy Policy Section.
The Copy Policy Section selection screen appears at the bottom of the screen. Here you enter the details
for the policy section to be copied.
4. Enter the values for the source policy section in the following fields:
5. Enter the values for the target premium in the following fields:
○ Target Policy Section (enter an ID that has not yet been used for a premium belonging to the specified
coverage)
○ Name of Policy Section (optional)
6. Choose Execute.
 Note
adjustment can occur: For example, you select Copy Value Insured and Do Not Copy Value Insured. In
this case, the system removes the selection for the value insured.

8. Choose Execute.
Results
1. The policy section has been copied.

The message lists the source policy IDs, the source policy section, and the target policy section, as well as
the number of copied subentities (policy section headers, policy sections, classes of business, business
types, and so on).
4.3.1.2.3 Valuation Date
Definition
The valuation date is the date used for fixing the exchange rate for currency translation.
Use
The system uses the valuation date for all currency translation for a policy section, such as:
● Translating currencies for non-statistical value types to the currency of the statistical value types
● Translating the original currency of the policy section into the local currency
● Translating all the statistical values dependent on this policy section into the local currency
● Translating currencies at all the relevant levels for calculating the statistical values and portfolio premiums,
when cessions are calculated, and when you create manual cessions (see Cession Group Creation [page
93] and Cession Calculation [page 95])
● During cession group creation, if the currency of the reinsurance program differs from the local currency.
You can define whether the currency should be translated at the start date or change date of the group
period. In this case, you cannot enter the valuation date manually.
● If the currency of the reinsurance program differs from the cession currency, the system uses the valuation
date of the corresponding cession group period to translate the amounts for the ceded policies and policy
sections.
 Note
For each valuation date, the system stores the valid-from date of the exchange rate determined for the
original currency of the policy section. This date is taken from the SAP exchange rate table.
● For more information about the valuation date in the context of the liability indicator, see the
documentation for the liability indicator.
Determination of the Valuation Date

You can make various default settings for the valuation date in Customizing (see below). If you define default
values you can still change them manually in the application.
Automatic Change to the Valuation Date
The system automatically determines the valuation date again in the following cases:
● When a new policy section, value insured, premium, or participation is created.

● Following a change in the accumulation, or a status change.
● When a policy, policy period, policy section, value insured, premium or participation is created by the copy
function, the relevant valuation dates are also stored.
● The system sets the valuation date at group level when you create cession groups or prior cession groups.
In this case, the date is only stored internally.
Fixed Valuation Date
To prevent your manual changes from being overwritten by the system when participations change you can set
the “Manual Change” checkbox. As long is this checkbox is set, the valuation date can be changed only
manually.
Default Settings
You can define the following default values for the valuation date at policy section journal level and participation
level in Customizing for Risk Manager (Non-Life):
● Start date as the valuation date: The valuation date changes only if you change the start date for the
policy section period or participation period. Other changes do not trigger a change in the valuation date.
(In the same way, the valuation date at value insured level is set to the start date of the value insured
journal, and the valuation date at premium level to the start date of the premium journal.)
Default Values Edit Defaults for Central RM Settings – column: PolValDate
You make the corresponding settings for participations in the same Customizing table in the column
PartValDte.
● Last change date as the valuation date: Every time you make a change to a policy section, the system
resets the valuation date for the corresponding policy section period. (In the same way, each change at
value insured level resets the valuation date at value insured level, and each change at premium level resets
the valuation date at premium level.)
Default Values Edit Defaults for Central RM Settings – column: PolValDate
You make the corresponding settings for participations in the same Customizing table in the column
PartValDte.
● Display in local currency or display currency: Default Values Edit Defaults for Central RM Settings –
column: CrcyPolSta
4.3.1.2.4 Status Control
Use
The status plays a key role when you edit policies, groups, and participations, or create accounts for these. The
status also controls the generation of complete historical statuses for policies and accumulations.
Statuses Open for Posting

If the status of a journal entry has the attribute Posting Allowed or Complete, you cannot edit the data for the
corresponding period.
A status with the attribute Posting Allowed can be set from the superior object only. Account postings can be
created only for objects with statuses that are open for posting.
You can use the background job Generate Complete History (/MSG/H_H_HISTORY_ASSEMBLER) to generate a
complete history, including all assigned objects, for the most recent status of a policy or accumulation that is
open for posting.
Features
Status Propagation
When the status of an object changes, the system also changes the status of dependent objects when you
perform the following activities:
● Cession group creation

● Reversal with calculation of returns
● Reversal without calculation of returns (restricted)
The system always uses the statuses defined in Customizing under FS-RI:Risk Manager (Non-Life) RM
Functions .
Status Change
You can change a status at policy and accumulation level only by choosing Confirm. The following rules apply:
● The status Posting Allowed/Not Reversed can be set only in the superior object by choosing Confirm.
● The status that allows posting is forwarded to all the assigned technical objects provided these objects do
not already have a reversed status.
● If a policy that is open for posting or an accumulation is set to "In Process" by choosing Confirm, then this
status is also forwarded to only those assigned technical objects that have not been reversed.
● Similarly, you can set the status Reversed only by choosing Confirm. This status is not forwarded to
assigned technical objects if these have already been reversed.
● You can also set the status Reversed in lower-level objects using the Status Change function.
● Part of the policy period is assigned to an accumulation. Both the policy and accumulation are in process. If
the policy is not confirmed with the status Posting Allowed/Not Reversed, then the status of the policy
header remains set to In Process.
You can change the status of the lower-level objects for a policy or an accumulation using the Status Change
function. The following rules apply:
● The status Posting Allowed/Not Reversed cannot be set using the Status Change function.
● Status changes at policy section level must always be propagated.
Check
The Functions Checked checkbox can be set for a status. If this checkbox is set for a status, the system runs
validation checks when this particular status is set.
Generation of Histories

You can use the Generate Complete History background job to synchronize the delta histories of a policy or an
accumulation into complete histories. When you use this job, a complete history, including all assigned objects,
is generated for the most recent status of a policy or accumulation that is open for posting.
If the policy or accumulation has never had a status that allows posting, then the complete history contains the
current operational data.
4.3.1.2.5 Copying Policies
Prerequisites
You can copy the policy section header if the following conditions have been met:
● The policy you want to copy exists in the system.

Context
You can use this procedure to copy an existing policy. This creates a new, independent policy.
Procedure
○ Copy Policy
○ Copy Premium
The Copy Policy selection screen appears at the bottom of the screen.

4. Enter the ID of the source policy.
5. Enter the ID of the target policy and a corresponding name.
 Note
If you do not enter an ID for the target policy, the system assigns the next available number to the
copied policy. Whichever option you choose, it is always useful to enter a name for the copy of the
policy.
6. Choose Execute.
 Note
adjustment can occur: For example, you select Copy Policy Section Value and Do Not Copy Policy
Section Header. In this case, the system removes the selection for the policy section value.
8. Choose Execute.
Results
1. The policy has been copied.
 Note
The system assigns the copied policy a status indicating that it was created as a copy. You define the
status values in Customizing.

The message lists the source and target policy IDs as well as the number of copied subentities (policy
section headers, policy sections, classes of business, business types, and so on).
4.3.2 Liability Aggregation
Use
This function takes the individual liability amounts for the base entities (values insured, coverages, or
participations), and calculates the total liabilities for the higher-level entities (policy sections or participations).

Prerequisites
● For liability aggregation up to accumulation level: A value type is assigned to each of the classes of
business as the liability calculation base for the original business side ( Master Data Classes of
Business Edit ). The liability calculation base is the value that reflects the liability and as such the risk to
be distributed, such as Sum Insured. When the liabilities are aggregated on the original side, the system
only includes values with this value type.
● At value insured level or policy section level you have defined values with these value types and set the
Relevant for Aggregation checkbox.
Features
Values Affected
The system determines the relevant values for the liability aggregation calculation on the basis of the main
class of business for the policy section and the Relevant for Aggregation setting.
You can only select this checkbox if the value is assigned a value type that has been assigned to the class of
business as a value type "relevant for liability" in the master data.
Calculating the Aggregated Liability for Individual Objects
You can calculate the total liability for the following objects.
Value Insured
You can enter liability totals only.
Subcoverage
The system calculates the liability totals from the values insured. You cannot enter liability totals manually.
Item
The system calculates the liability totals in different ways, depending on the existing data in Basic System. It
searches for the relevant Basic System data in a certain order of priority and uses the first entries it finds. The
order of priority is as follows:
1. LUDs at policy section level

2. LUDs at value insured level
3. Values at value insured level with the Relevant for Aggregation checkbox set
4. Values at policy section level with the Relevant for Aggregation checkbox set
Policy
The system calculates the liability totals on the basis of the policy sections. You cannot enter the values
manually.
Accumulation Group
The system calculates the liability totals on the basis of the policies. You cannot enter the values manually.
Participation

● Proportional participations: The system calculates the liability totals from the totals for the preceding
groups, applying the specified participation percentage rate.
● Non-proportional participation: The system calculates the liability totals using the totals for the preceding
groups and the LUDs for the participation.
● The system does not include the Carve-Out checkbox when it aggregates liabilities at participation level. If
necessary, you must manually correct the liability amount that was calculated by the system. You are
responsible for defining the total liability.
Liability Aggregation Methods
The system uses the following aggregation methods:
● Maximum: For example, the maximum liability of the values insured is entered for the higher-level
coverage.
● Minimum: For example, the minimum liability of the values insured is entered for the higher-level coverage.
● Average: For example, the average liability of the values insured is entered for the higher-level coverage.
● Total: For example, the total liability of all the values insured is entered for the higher-level coverage.
Gross Liability, Remaining Liability, and Prior Cessions
If no prior cession group has been assigned to the participation, the gross liability is the same as the remaining
liability. If a prior cession group has been assigned, the remaining liability is reduced by the percentage rate
specified for the participation.
Valuation Date
When the system calculates the statistical values for policy sections, values insured and premiums, it uses the
respective valuation date and the exchange rates for that date.
Display of the Liability Totals
Liability Aggregation at Policy and Accumulation Level
The system discloses assumed liabilities separately for obligatory and facultative participations. A participation
is classified as obligatory or facultative on the basis of the “Nature of Treaty” setting for the treaty assigned to
the participation.
Differentiation by Original Policy/Participation
The totals also distinguish between original values and participation values. These values are differentiated by
company code, which is necessary when more than one company code participates in an original policy or in an
accumulation.
Differentiation by Mode
The liabilities are displayed for the relevant mode (occurrence year, underwriting date). Risk Manager Non-Life
only supports the Accounting Year mode in the sense that treaties based on the accounting year can be
assigned to Risk Manager Non-Life; these treaties are handled in Risk Manager Non-Life in the same way as
treaties based on the occurrence year.
LUDs
The LUDs for the participations can be included in the calculation for the total assumed liability. However, you
need to explicitly specify the limit to be included in the calculation by selecting the “Use for Cession
Calculation” checkbox. In this case, the system ignores the structural characteristics that have been defined
for these limits and deductibles.

Activities
You execute the liability aggregation function manually or as a background job.
1. Determine values in Basic System

○ The system checks if values insured exist that are relevant for liability aggregation (Relevant for
Aggregation checkbox set). If this is the case, the system starts to aggregate the liabilities at value
insured level or coverage level. Otherwise, it starts to aggregate the liabilities at policy section level.
○ The system determines the value types to be used as the liability calculation base for the class of
business assigned to the value insured. There is one value type for the original side, and one for the
participation side.
○ If no values insured have been defined as relevant for liability for a given policy section period, the
system uses the values for the value types of the policy section.
2. Aggregation at coverage level
The system aggregates liability calculation bases for values insured at the coverage level above on the
basis of the mode (occurrence year or underwriting year) and the defined calculation method (total,
average, maximum, minimum). It does this for all values insured in all coverages if the Relevant for
Aggregation checkbox has been set. The results of this calculation are stored as statistical values at
coverage level.
3. Aggregation at policy section level
The system aggregates the statistical values for all coverages at policy section level, taking into account the
mode and calculation method. The results of this calculation are stored as statistical values at policy
section level.
4.3.2.1 Liability Aggregation Depending on the Mode
Use
An assumed policy can contain policy sections that differ as follows: For each policy section header you can
specify whether the related policy section periods should be assigned the mode "Occurrence Year" or
"Underwriting Year". In some cases, accounts for policies that cover multi-line business (such as third-party
liability and fire coverage) may relate to both the underwriting year and the occurrence year. That is, different
modes may apply within a single policy. These policy sections are handled differently by the liability
aggregation function, depending on the mode you have selected.
Features
You define the mode for a policy section header (underwriting year or occurrence year) in the policy section
header itself. This means that a single policy can have policy section headers with different modes. Since the
premiums and values insured are dependent on the policy section header, they must have the same mode as
the policy section header itself. The underwriting year (or underwriting date in Risk Manager Non-Life) can vary
between the time periods for a policy section.
The liability aggregation function is executed for each underwriting year and occurrence year. Therefore, on the
assumed business side, it is based the modes in the policy section headers for the assumed policy.

The statistics for policy sections based on the underwriting year must be calculated for each underwriting date
and occurrence year. This is particularly important for accumulating the statistical values at a higher level. The
liability totals for occurrence year-based policy sections and underwriting year-based policy sections must
never be accumulated jointly. In addition, the statistics for the policy sections with a given mode (such as
underwriting year) can only be accumulated if both the general criteria (value type, class of business, line of
business) and the underwriting date match exactly.
4.4 Grouping of Original Business
Use
In this step you can structure the assumed business in the original policy by grouping policy sections.
Prerequisites
You have created the policies and policy sections to be grouped.
Process
Policy Section Groups
Policy section groups are used to link policy sections and participations. You assign policy sections on the
“assumed business” side, and participations on the “ceded business” side. The ceded participation assigned to
the policy section group can be one of the following:
● Original layer
● Cedent participation
● Your company's own assumed participation
You can assign policy sections from different original polices to one policy section group if these original
policies belong to the same accumulation group. Otherwise, you can only group policy sections from the same
policy.
You must create policy section groups if you want to define participations in an original policy. The system
therefore allows you to create policy section groups and the ceded participations for this policy section group in
a single step.
For more information, see Creating Policy Section Groups and Participations for Policy Sections [page 80].
Automatic Accumulation Control
You can use the accumulation control function to determine accumulations automatically. The function finds
policies that cover the same object, for example, and groups them accordingly.
For more information, see Accumulation Control [page 84].

Manual Definition of Accumulations
If you are unable to use the automatic accumulation control function, or decide not to, you can still assign
original policies to an accumulation group [page 82] manually.
Result
Individual policy sections are assigned to groups. In the next step, you can create ceded participations for these
policy section groups. The role of the ceded participation can vary, as described above.
4.4.1 Policy Section Group
A policy section group is a form of cession group to which you assign policy sections on the “assumed
business” side instead of participations. Policy section groups group matching original policy sections. They
form the basis for participations, which you assign to the group as ceded participations.
A participation can only reference an cession group (in this case, a policy section group). This means that you
always need a policy section group, even if you only want to create a participation in a single policy section.
The group category of the policy section group is also “cession group”.
For more information, see Cession Group [page 125].
4.4.1.1 Creating Policy Section Groups and Participations

for Policy Sections
Prerequisites
You have created the policy sections you want to group and for which you want to create a participation.
Context
You use this procedure to assign a policy section group to an existing policy section. At the same time, you can
create a ceded participation for this policy section group.

 Note
You cannot create a direct link between a participation and a policy section without using a policy section
group in between. This means that you still have to create a policy section group even if you only want to
link the participation to a single policy section.
Procedure
1. At policy header level, switch to the Pol. Sec. Grouping tab page.
2. In the Policy Sections table, select the policy sections for which you want to create a group.
3. In the application toolbar, choose the pushbutton.

4. Enter the required data and the desired optional data in the dialog box. Choose a group category with the
type Cession Group and the level Journal, such as the group category Cession with Journal. In the first row
of the Participation Data section, specify whether you want to create a participation for the group at the
same time, or whether you want to assign an existing participation.
5. Confirm the entries you have made in the dialog box.
4.4.2 Accumulation Functions
Use
You map accumulations in the FS-RI system by creating accumulation groups. An accumulation group contains
the policies that form an accumulation. You can then reference the accumulation group containing several
policies when you process retrocessions, rather than just one policy.
Features
● Automatic accumulation control [page 84]: The system searches for existing accumulation groups with
the same characteristics and assigns the policy to one of accumulation groups found.
● You can create accumulation groups [page 83] manually.
● The function for creating cession groups [page 93] references the accumulation group, enabling joint
coverage and retrocession of the policies in an accumulation group.
● The system checks and correct reallocation if a policy section is moved into or out of an accumulation
group. For more information, see Change in Accumulation Assignment [page 86].
● The system analyzes policies assumed by various companies in a corporate group as an overall
accumulation [page 105].

4.4.2.1 Accumulation Group
Definition
An accumulation group comprises one or more policies. The system can then perform a joint retrocession for
all participations linked to an accumulation group, based on certain rules (portfolio treaties).
Use
You use accumulation groups to group policies and retrocede them together, so that your own share only
applies once for the entire accumulation group. For more information about how accumulations are handled for
retrocession purposes, see Cession Group Creation [page 93].
The system also calculates the total liability for the entire accumulation group. For more information, see
Liability Aggregation [page 75].
Company Codes
You can combine policies from different company codes in one accumulation group. To avoid problems later on,
you must define each company code you use as a central company code in external Customizing for FS-RI Risk
Manager (Non-Life) under General Settings Configure Company Codes .
Authorization Check for Accumulation Group
You must make the appropriate setting for the authorization check in Customizing for FS-RI Risk Manager
(Non-Life) under Policy Administration Edit Assignment of Application to Authorizations .
The system determines the responsibilities for the accumulation group, followed by the partners assigned to
the corresponding roles. It then selects the department and position of these partners (if defined) and uses
them as fields for the authorization check in authorization object YRVN_GRP.
If no department or position is found (new accumulation group, role was not assigned to an “old” accumulation
group, no department or position has been assigned to the partner), the system enters dummy values in the
corresponding fields. This means that the organizational unit and position are not included in the authorization
check.
The authorization check is applied only to the remaining fields in authorization object YRVN_GRP. These
remaining fields are checked for the current user, and include the current mode (create, change, display a
group), the current group number, and the current company code.
A user has access to an accumulation group if one of the responsibilities matches (OR relationship).
Validation Checks for Accumulation Group
The system checks the accumulation group for the following:
● Assignment period: the start date must be before the end date.
● If the time rule is set to 12:00 hrs or 00:00 hrs, the start and end dates must not be identical.
● The assignment period must fall within the group and policy/certificate header periods.
● The assignment periods must not overlap within a policy or accumulation.

● Change in accumulation group: each group/policy section assignment or group/participation assignment
must be uniquely assigned to a single accumulation or policy. Groups cannot be used for more than one
accumulation.
● Warning: The policy period is greater than the assignment period for the accumulation.
4.4.2.1.1 Creating Accumulation Groups
Use
You can group policies and policy sections of the same type in accumulation groups.
Procedure
You can create accumulation groups in various ways.
Create from Initial Screen
For more information, see Initial Screen for Processing Policies, Groups, and Participations [page 34].
Create from Policy or Participation
1. Choose . You can use this option only if the existing accumulation group assignments do not cover the
entire policy header period.
2. The system automatically assigns the new accumulation group to the header of the policy you are editing.
This assignment is displayed on the Group Assignment tab page. You can change the assignment date on
this tab page.
 Note
When you create the group, the system writes it to the database immediately. This step cannot be reversed.
4.4.2.1.2 Authorization Check for Accumulation Group
You must make the appropriate setting for the authorization check in Customizing for FS-RI Reinsurance under
FS-RI Risk Manager (Non-Life) Policy Administration Edit Assignment of Application to Authorizations .
The system determines the responsibilities for the accumulation group, followed by the partners assigned to
the corresponding roles. It then selects the department and position of these partners (if defined) and uses
them as fields for the authorization check in authorization object YRVN_GRP.
If no department or position is found (new accumulation group, role was not assigned to an “old” accumulation
group, no department or position has been assigned to the partner), the system enters dummy values in the
corresponding fields. This means that the organizational unit and position are not included in the authorization
check.

The authorization check is applied only to the remaining fields in authorization object YRVN_GRP. These
remaining fields are checked for the current user, and include the current mode (create, change, display a
group), the current group number, and the current company code.
A user has access to an accumulation group if one of the responsibilities matches (OR relationship).
4.4.2.1.3 Validation Checks for Accumulation Group
The system checks the accumulation group for the following:
● Assignment period: the start date must be before the end date.
● If the time rule is set to 12:00 hrs or 00:00 hrs, the start and end dates must not be identical.
● The assignment period must fall within the group and policy/certificate header periods.
● The assignment periods must not overlap within a policy or accumulation.
● Change in accumulation group: each group/policy section assignment or group/participation assignment
must be uniquely assigned to a single accumulation or policy. Groups cannot be used for more than one
accumulation.
 Caution
The policy period is greater than the assignment period for the accumulation.
4.4.2.2 Accumulation Control
Use
You use the accumulation control function to find the matching accumulation groups to which a policy could be
assigned.
Prerequisites
● A value has been entered in either the Policyholder or Object field for the policy. To yield better results, both
fields should be filled.
● You have defined the business partner relationships for accumulation control in Customizing. As a result,
the accumulation control function can also recognize partner companies of the policyholder to be included
in the accumulation, such as group parent companies and subsidiaries. You make these settings in external
Customizing for FS-RI Risk Manager (Non-Life) under Accumulation Control Define BP Relationship
Categories for Accumulation Control .

Features
The system searches for existing policies or accumulation groups that could form an accumulation together
with the policy being processed. An accumulation can be formed if the policy or accumulation group is
assigned to the same chain of company codes and at least has the same policyholder or covers the same
object.
The system lists all the accumulation groups and policies found (including the policyholder, object, and text for
each policy). The list is sorted on the basis of the weighting defined in Customizing.
If you double-click one of the policies or groups in the list of results, the system automatically branches to the
display screen for the corresponding policy or group.
Assigning a Policy to an Accumulation Group
To assign the policy being processed to an accumulation group, you select an accumulation group and choose
Assign Policy to an Accumulation Group. The system tries to assign as much of the policy period as possible to
the group, subject to the checks described below.
Generating New Accumulation Groups
If you cannot find a suitable accumulation group, you can create a new one. Under Policies, you choose the
policies that you want to bundle in an accumulation group with the policy being processed and then choose
Assign Policies to a New Group. The system tries to assign as much of the policy period as possible to the
group. After the new group has been assigned, the system returns to the processing dialog for the policy.
Affiliated Companies
If no accumulation groups are found for the specified policyholder, the system tries to find an affiliated
company using the search relationship categories defined in Customizing. This is possible only if you have
entered the values in the relationships table in Customizing and have assigned the affiliated companies in the
SAP Business Partner module.
Checks
The system checks the following when a policy is assigned to a group and when a new group is created in the
background:
● The period for which the policy is assigned to the group falls within the group period
● A policy is not be assigned to the same group category more than once for the same time period
Activities
1. In an open policy, choose or F8 .

2. The system searches for accumulation groups and policies that match the current policy and displays the
results in a table.
3. You then decide how to proceed. You have the following options:
○ Assign the policy to one of the accumulation groups found by the system
○ Generate a new accumulation group that contains the current policy and selected policies from the
search results

4.4.2.3 Change in Accumulation Assignment
Use
Whenever you assign an original policy to a new or different accumulation, the superior object changes. If a
policy is not assigned to an accumulation, this policy itself is the superior object. If you assign the policy to an
accumulation group, the accumulation group becomes the new superior object. This is important for creating
cession groups and calculating cessions, since both functions reference the superior object. Consequently, you
need to execute the functions for cession group creation and cession calculation for the new or changed
superior objects after reassigning an accumulation.
Features
The change in the accumulation assignment can take the following forms:
● An original policy does not belong to an accumulation and you assign it to an accumulation for the first
time.
● An original policy is currently assigned to an accumulation, and you delete the accumulation assignment to
handle the policy separately.
● An original policy assigned to one accumulation and you reassign it to another accumulation for the entire
policy term.
● An original policy is assigned to an accumulation for its entire term, and you want to assign it to different
accumulations for specified periods, or have certain periods during which the policy is not assigned to an
accumulation.
Consistency Checks
Checks During Confirmation
When you confirm [page 72] a participation chain, the system checks whether all the necessary cession groups
have been created and whether all the cessions have been calculated. If this is not the case, it returns an error
message.
Validation Checks
The validation checks ensure that the object relationships are consistent after a change in the accumulation
assignment.
● If the system detects an overlap between the accumulation assignment and an automatic cession group
assignment, the cession group assignment is shortened or deleted. You must adjust prior cession groups
or manual groups manually before you change the accumulation assignment.
● When you delete an accumulation assignment, the system checks if existing manual cession groups and
prior cession groups are assigned to different policies at the same time. If the system returns an error
message, you must decide which policy section header/accumulation group assignment you want to keep.
● If you change an existing accumulation assignment, the system checks whether manual cession groups or
prior cession groups are only assigned to a single superior object. If this condition is not met, you cannot
exit the subscreen.
● If you assign a policy section or participation to a manual group or prior cession group, the system checks
whether this group is already assigned to a different superior object. If this is the case, the system rejects
the new assignment.

● If you change an existing assignment for a policy section or participation to a manual cession group or prior
cession group, the system checks whether this group is already assigned to a different superior object. If
this is the case, the system rejects the new assignment and does not allow you to exit the subscreen.
Valuation Date
If you change the accumulation assignment, this can divide the entire assumed business side for the affected
policies (periods for policies, policy sections, values insured, and premiums). As a result, you may need to
change the corresponding valuation dates [page 71].
4.5 Definition of Participations
Use
You follow this process to define the portion of the risk retained by the primary insurer, the portion assumed by
your cedent, the portion you assume (which may be spread across several subsidiaries), and the part you cede
to a retrocessionaire.
Prerequisites
● The original business [page 36] has been defined in full.

● The cessions from the original business are grouped in policy section groups [page 80] and, if necessary, in
accumulation groups [page 81].
Process
Structure of the Participation Chain
You always define participations in the form of a chain.
You can begin with the participation of the primary insurer (P), for example.
You then define the participation of the reinsurer (R1) in the business of the primary insurer (P) and so on, until
you reach your own company.
For your own company you define assumed participations and ceded participations. You can also define
connecting participations if you work with several company codes (subsidiaries).
You can also leave out individual links in the chain. You can define your own participation as a direct
participation in the primary insurance business or original policy, even though other reinsurers come before
you. For example, R1 might have a participation of 40% of P of 50% of the original. You could enter this in the
system as 20% of the original.
Groups and Participations

The FS-RI object Participation can reference only the FS-RI object Group. Therefore, there must always be a
group between two participations, or between a participation and a policy section. The group is the technical
connector.
In other words, original business from the policy section is ceded to group 1. Participation 1 defines the
participation of R1 in group 1, and cedes a portion of the risk to group 2. R2 participates in group 2 and cedes a
part of the risk to group 3, and so on.
For more information, see
● Cession Group [page 125]

● Participation [page 106]
Partial Coverage (Carve-Out)
You can define partial coverages (carve-outs). A partial coverage is when the ceded business side covers only
part of the assumed business.
A carve-out can be represented by two variants:
1. Exclusions are defined for the ceded Risk Manager participation.

2. The treaty for the ceded participation covers only some of the structural characteristics of the logical
policy sections or participations.
You can select cession groups via manual processing (Carve-Out checkbox). When you do this, the system
restricts its checking of all the structural characteristics and deactivates its checking of the cession totals.
Creating Participations
1. Create the cedent participations and the groups up to the cession group of your cedent as you require. For
more information, see Cedent Business [page 88].
2. Create your own participation by defining the portion of the risk you are assuming yourself. For more
information, see Assumed Business [page 89].
3. Define the portion of the assumed risk you want to retain and the share you want to cede, and specify the
relevant assumed and ceded treaties to which you want to assign the risk. For more information, see
Retention and Ceded Business [page 90].
4. Confirm [page 133] the data for the original policy and the participation chain.
Result
You have mapped the structure of the participation in the original policy at the desired level of detail.
If the status of the participation structure allows posting, you can create accounts for premiums and losses.
4.5.1 Cedent Business
Use
If you have information about the participations of partners that come between the primary insurer and your
company in the participation chain, you can use this process to map them in the system.

You can then choose whether to define your own assumed participation as a share in the partner's business, or
as a share in the original policy.
Prerequisites
You have entered the original business.
Process
1. Create a participation for each cedent whose business you want to map in the system. In this participation,
specify the share of the cession group being assumed from the preceding cedent. Use a participation type
with the attribute "For Information Only", since you do not want to create accounts for the cedent's
participation. For more information, see Participation [page 106].
2. Create a cession group for the cedent participation. In the cession group, you define the share of the risk
ceded by the cedent. For more information, see Creating Cession Groups and Participations [page 119].
3. Repeat steps 1 and 2 until you reach your own participation. For more information about how to proceed
from there, see Assumed Business [page 89].
 Note
Always start with the first link in the chain that you want to map in the system.
4.5.2 Assumed Business
Use
You follow this process to define your share in the original risk. You can define the share directly, or define it
indirectly as a share in the share of a partner.
Prerequisites
● You have entered the original business.

● If you want to define your participation as a share in the participation of a partner who is not the primary
insurer, you must enter the partner's share first. For more information, see Cedent Business [page 88].

Process
You create your participation in a cession group for an original policy section or for a cedent participation. You
can use a facultative or obligatory participation type. For more information, see Participation [page 106].
Result
You have defined the assumed business and can now define your retention and ceded shares [page 90].
4.5.2.1 Special Certificate
Definition
A special certificate is a certificate that is covered by an assumed obligatory treaty even though the upper
liability limit and the scope of the structure exceeds the scope of the obligatory treaty.
Use
To create a special certificate, create a participation using a participation type with the attribute “Special
Certificate” as the nature of the participation.
The structure of this type of participation is not checked against that of the master treaty.
You can only create special certificates in Risk Manager Non-Life for information purposes. Accounts cannot be
created in Risk Manager. All accounting activities must be carried out in Basic System.
It is also not possible to define conditions for special certificates, or to link them to the retrocession side.
4.5.3 Retention and Ceded Business
Use
You follow this process to distribute the risks you have assumed. This includes:
● Determining your retention and distributing it to your assumed treaties

● Assigning the correct ceded reinsurance treaties for passing on the risk
● Recognizing and handling unplaced risk

Prerequisites
● You have created the assumed participations.

● You have performed the following activities in the correct order. This allows you to use the automatic
system functions for creating cession groups and calculating cessions.
1. You have created the treaties to which you want to cede risks from the participation. For more
information, see the documentation for Basic System under “Treaty”.
2. You have defined the reinsurance programs [page 690] defining the extent of the liability to be
assumed by the treaties, and have assigned the treaties to this program.
3. You have defined the portfolio treaty [page 92] that references the reinsurance programs and
assigned the reinsurance programs to it.
Process
1. Optional: You can specify the shares of the risk you want to cede manually before the rest is distributed
according to the defined rules. For more information, see Prior Cession Group [page 127].
2. Assign the portfolio treaty [page 92] to the assumed participation.
3. Execute the cession group creation [page 93] function for the participation. If there is more than one
participation for the same superior object (policy or accumulation), the system analyzes the participations,
which may have identical or different structural characteristics, and groups them into homogenous cession
groups based on the structure of the assigned portfolio treaty sections. The total for the cession group
then forms the basis for the cession calculation. Each cession group matches a section of the assigned
portfolio treaty, which means it is also allocated to the reinsurance program assigned to this portfolio
treaty section.
4. Start the cession calculation [page 95] run for the cession group. The system distributes the risk for the
cession group to the treaties in the reinsurance program defined for the portfolio treaty section.
5. Optional (instead of steps 3-5): Create the cessions manually. For more information, see Manual Cessions
[page 128].
6. Check the result and decide how to handle the amounts still not covered. You can either add them to the
retention or assign them to a suitable treaty. For more information, see Handling Unplaced Risk [page 130].
Result
For each premium or loss payment you enter for a participation on the assumed business side, the system
calculates and generates corresponding postings for the reinsurance treaties affected.
Example
You have three policies, each with two policy sections. The structural characteristics are identical except for the
class of business. Two of the policies are assigned to an accumulation group.

You let the system distribute the risks automatically and do not define prior cessions or enter manual cessions.
There is no unplaced risk left after distribution.
Related Information
Treaty [page 194]
4.5.3.1 Portfolio Treaty
Definition
Portfolio (PTF) treaties are used to assign single risks from Risk Manager to the correct reinsurance program.
For more information about the role of the PTF treaty, see Cession Group Creation [page 93]. A PTF treaty is
not a real treaty. It does not map an agreement between two business partners and you cannot create
accounts for it.
The PTF treaty maps the structure of your portfolio, which is defined by the individual treaty sections.
Use
Assignment of Participations to Reinsurance Programs
The function for creating cession groups references the PTF treaty to distribute the risks to the various cession
groups and to assign these cession groups to the different reinsurance programs.
The key information is stored in the PTF treaty sections. Each PTF treaty section is assigned to a single
reinsurance program. For example, if you have a reinsurance program for the class of business “Fire”, and
another for the class of business “Third Party Liability”, you create two PTF treaty sections. You then assign the
reinsurance programs to the sections for the respective class of business. If you create cession groups for two
participations that each involve one of these classes of business, the system recognizes that the classes of
business are covered by different reinsurance programs by looking at the PTF treaty sections. It then creates
separate cession groups and assigns them to the respective program.
Structure
To use a treaty as a PTF treaty, you must set it up as follows:
1. It must have a treaty type for which the PTF Treaty checkbox is set (usually, the name of the treaty type is
also “PTF Treaty”).
2. The Use in Risk Manager checkbox must be set at treaty header level.
3. The term of the period in the PTF treaty must be within or the same as the periods defined for the treaties
in the reinsurance program.

 Note
By default, every reinsurance program you create is valid until December 31, 9999. To restrict the
validity period for a reinsurance program, you create a new reinsurance program period. The original
period then ends on the day before the new period begins.
4. The PTF treaty must have one treaty section for each reinsurance program you want to “assign” via this
PTF treaty. The structural characteristics of this section must match those of the treaties defined in the
reinsurance program. In this section, you assign the reinsurance program on the Section tab page under
Structure Elements.
5. The PTF treaty must have a status that allows posting and is not a reversal status.
Example
For an example of the process, see Example: Creating Portfolio Treaties [page 183].
4.5.3.2 Cession Group Creation
Use
This function assigns assumed participations to cession groups when certain conditions are met.
If an accumulation group covers the same risks for different policies, and certain other prerequisites are
fulfilled, these policies can be assigned to a cession group.
Integration
Distributing single assumed risks to reinsurance treaties involves two steps. You create the cession groups in
the first step and calculate the cessions [page 95] in the second.
Prerequisites
● You have made the settings for creating cession groups in external Customizing for FS-RI Risk Manager
(Non-Life) under RM Functions Edit Function for Creating Cession Groups . This includes default
settings for the status, change reason, group category, and liability indicator.
● You have created a corresponding portfolio treaty [page 92].
● You have assigned a portfolio treaty to the participations for which you want to create cession groups.

Features
The system compares the structural characteristics of the participations being processed with the treaty
sections of the assigned portfolio treaty. It then creates a cession group for each matching section of the
portfolio treaty, and assigns the liabilities of the participations to the relevant cession groups.
The system also assigns the values for the cession calculation criteria to the cession group (such as
construction type class or statistical account). You define these values in Customizing for Basic System under
Interfaces RM Connection RIP Settings Edit RIP Defaults for Cession Calculation Criteria .
Cession Group Journals
The journals for cession groups are created on the basis of the statistical net liabilities for the assigned
participations. For each day in the validity period of the cession group, the system calculates the total liability
on the basis of the assumed participations. It then creates a journal for each uninterrupted period that is not
subject to changes.
For each cession group journal the system also determines which Extension Service is relevant for supplying
the default values for the cession calculation criteria. It does this by comparing all the possible Extension
Services for group periods to the reinsurance program class model [page 61] that has been defined for the
respective cession group.
Once the relevant Extension Service has been established, the system determines the values for the cession
calculation criteria.
 Note
You define the calculation rules for the default values for the cession calculation criteria in Customizing for
Basic System under Interfaces RM Connection RIP Settings Edit RIP Defaults for Cession
Calculation Criteria .
Retrospective Changes
● If you assign a policy to an accumulation group after cession groups have already been created, or move a
policy from one accumulation group to another, the participations belonging to this policy need to be
reassigned to the correct cession groups. In this case, you must re-run the functions for creating cession
groups and calculating cessions.
● If you change the structure of a policy section and thus the structure of the assigned participations, you
must check whether the assigned portfolio treaty section still matches. You do this using the Check
pushbutton, or by repeating the cession group creation run. In the latter case, the system makes any
necessary adjustments immediately. If the assignment to a cession group changes, the system displays a
message indicating that the cessions need to be recalculated for the cession groups affected.
Automatic/Manual Cession Groups
The system creates a cession group for each matching portfolio treaty section. The cession groups created by
this function are regarded as automatically-created cession groups. You cannot make manual assignments to
these automatic cession groups. They can be used only by the system function for creating cession groups.
However, you can still create manual cessions. For more information, see Manual Cessions [page 128].

Activities
1. You call the Cession Group Creation function from within the participation using the corresponding
pushbutton.
2. The function checks whether participations exist that have not yet been assigned. Any existing
assignments are kept.
3. The function determines which assumed participations can be grouped in cession groups, and creates
these groups accordingly. For each combination of structural characteristics in the participations, it looks
for a matching portfolio treaty section. The structure of the portfolio treaty may have a broader scope than
that of the participation (however, this does not apply the other way round). Several participations from
different policies (in the same accumulation group) can be assigned to the same cession group, as long as
these participations have been assigned to the same portfolio section.
○ If the policy is already assigned to an accumulation group, the system searches within the
accumulation group for a cession group that is assigned to the same portfolio treaty section as the
participation. If no corresponding cession group is found, it creates a new cession group within the
accumulation group (status “In Process”). This cession group then references the correct portfolio
treaty section.
○ If the policy containing the participation is not assigned to an accumulation group, the system can only
search for the relevant cession group in the available set of cession groups assigned to this policy. If no
cession group is found, it creates a cession group for the policy participation.
Example
For an example of the process, see Example: Creating Cession Groups [page 189].
4.5.3.3 Cession Calculation
Use
The cession calculation function distributes the liability of a cession group [page 93] to the retention (if a
retention amount has been defined) and to matching reinsurance treaties; if the reinsurance program has been
assigned the rank category S, this liability is distributed to the additional retention according to the threshold
value. The retention, the additional retention, and the matching reinsurance treaties are defined in a
reinsurance program [page 690].
Prerequisites
● The reinsurance program [page 690] and portfolio treaty [page 92] have been created and have a status
that allows posting and is not a reversal status.
● The Cession Group Creation [page 93] function has been executed.

● The cession groups for which you want to create the cessions have been assigned a status with the
attribute “In Process”.
Features
The system reads the liability amount from the “Total Liability” field for the cession group. In the standard
system, the default value for the total liability is the remaining liability calculated using the rules for liability
aggregation.
The system distributes the liability from the cession group to the treaties defined in the reinsurance program
based on the reinsurance program rules. It utilizes the capacity of the treaties in ascending order according to
rank and reference rank, until either the total liability has been distributed or there are no further treaties in the
reinsurance program to assume the liability.
For more information about how the system allocates liability to the individual treaties, see Allocation of
Individual Rank and Treaty Categories During Cession Calculation [page 97]. The system creates a ceded
participation for the retention ranks of the reinsurance program and for each reinsurance treaty that assumes
part of the coverage. Participations are also created for the NP coverages contained in the reinsurance program
that do not have any burden because the liability has been distributed in its entirety.
The cession calculation function also handles obligatory connecting treaties and generates connecting
participations. For more information, see Obligatory Connecting Treaties in the Reinsurance Program [page
104] and Allocation of Individual Rank and Treaty Categories During Cession Calculation [page 97].
Risk Classes
You can also incorporate a class model with a corresponding set of classes. For example, the class model
“Security Standards” might contain the classes “With Sprinkler System” and “Without Sprinkler System”. For
more information about how risk classes are handled by the cession calculation function, see Risk Classes for
Cession Calculation [page 99].
Activities
1. You can execute the cession calculation run as a background job, or call it from the screen for the cession
group (Calculate Cessions or Cession Calculation for Period pushbutton).
2. The system calculates a cession proposal based on the portfolio section specified in the cession group
header and the reinsurance program assigned to this portfolio section. This proposal lists all the ceded
participations with the corresponding cession percentages.
3. You can accept or reject the proposal. If you reject it, the system deletes the participations created by the
cession calculation function. You can also create ceded participations manually.
4. These manual changes are recognized by the cession calculation function. When the cession calculation
function establishes that a manual change has been made within a cession group, it sends a query to the
employee responsible asking whether the manual changes should be kept or deleted. If the manual
changes are to be kept, the cession calculation run does not affect these cessions. The cession calculation
function uses up the capacity of the individual ranks in the reinsurance program in the predefined
sequence. If one of the ranks (cessions) is affected by a manual change that is to be kept, the changed
cession is used to calculate the reduction in the total liability.

 Note
Due to the manual changes being kept, the total liability cannot be 100% distributed, making additional
manual adjustments necessary. This is because keeping the changes made manually to the cession
introduces a constant component, and only the automatic cessions can be adjusted flexibly.
5. The system calculates the cessions according to your specifications.
 Note
If you use the background job to calculate cessions you cannot make any manual changes.
Example
For an example of the process, see Example: Calculating Cessions and Confirmation [page 190].
4.5.3.3.1 Allocation of Individual Rank and Treaty

Categories During Cession Calculation
You can enter the following rank categories and treaty categories in the reinsurance program [page 690], which
are then used by the system to calculate cessions [page 95]:
● Quota share treaty with maximum liability

● Surplus treaty (with utilization)
● Non-proportional (NP) treaty
● Explicit retention
● Additional retention
In the reinsurance program you assign a rank to each treaty.
Each rank – and as such, each treaty in the reinsurance program – is assigned in relation to a preceding rank or
preceding treaty. This is defined by the reference rank.
In reinsurance programs [page 690] with a flexible format, each rank covers the amount that is defined as the
calculation base via the reference rank and the coverage reference and that does not exceed the maximum
liability of the treaty itself.
In reinsurance programs with the previous format, each rank covers the amount that is left over by the
reference rank and does not exceed the maximum liability of the treaty itself. This is the unplaced risk.
Application of a Quota Share Treaty
The system first determines whether the open exposure handed down from the reference rank is below or
above the maximum liability of the quota share treaty.

● If the total amount to be covered exceeds the maximum liability, the cession percentage rate for the quota
share treaty is applied to the maximum liability. Depending on the control indicator for retention (RIPRA in
reinsurance programs with flexible format) or the maximum liability indicator (1 for reinsurance programs
with previous format), the difference between the maximum liability and the liability of the quote share
treaty (the quota share retention) is added to the retention in the reinsurance program. Otherwise, you
must cover the quota share retention with other ranks or the amount is transferred to the unplaced risk.
● If the amount to be covered falls below the maximum liability, the cession percentage rate for the quota
share treaty is applied to the amount still to be covered. You must define the handling of the quota share
retention accordingly.
Application of a Surplus Treaty
The system determines whether or not a utilization percentage has been specified for the surplus treaty.
● If no utilization percentage has been entered, the treaty is used to cover the defined currency units
(retained line x number of lines). If the remaining amount to be covered is less than the calculated number
of currency units that would be covered by the treaty, the treaty is only used to cover the remaining
amount. The total covered by the surplus treaty is then converted into a cession percentage rate.
● If a utilization percentage has been specified, the surplus treaty does not assume the maximum liability it
could cover, but only a certain percentage of this capacity. This is the utilization percentage. However, if the
remaining amount to be covered is between the utilization amount and the maximum capacity, the surplus
treaty still covers the full amount. If the remaining amount to be covered would exceed the maximum
capacity of the surplus treaty, only the utilization percentage is ceded to the surplus treaty.
This type of buffer enables you to respond to fluctuations in the total liability between the utilization
percentage and the maximum capacity of the surplus treaty, and reduces the amount of manual work
involved.
 Example
Surplus treaty, retained line 10 million, number of lines 5, utilization 80%

○ Case 1: Total to be covered = 30 million
This amount is fully covered by the surplus treaty.
The surplus treaty only covers 40 million, which is 80% of the maximum capacity, and therefore
corresponds exactly to the defined utilization. The remaining 20 million is passed on to the
subsequent ranks of the reinsurance program.
This amount can be covered by increasing the utilization to 100%.
● Regardless of the utilization percentage, the retained line can be applied as a retention in reinsurance
programs with a flexible format if the corresponding entry has been made for the control indicator for
retention. You must define a separate rank with the rank category “Retention” for reinsurance program in
the previous format.

Application of a Non-Proportional Treaty
In NP treaties, the liability data for the deductible, liability, and protected share is taken from the treaty
definition. The protected share is applied to the LUD data. The deductible can be applied as a retention in
reinsurance programs with a flexible format if the corresponding entry has been made for the control indicator
for retention. You must define a separate rank with the rank category “Retention” for reinsurance program in
the previous format.
The risk below is only retained if it is not covered by treaties in lower layers. The liability specifies the total that
can be covered by the treaty after taking the deductible into account.
Obligatory Connecting Treaty
If the treaty is an obligatory connecting treaty (see also Obligatory Connecting Treaties in the Reinsurance
Program [page 104]), the participation is created for the corresponding treaty category. However, in the
standard system, this participation is assigned the cession rule “No Cession” and is not assigned a portfolio
treaty. You have to edit these details later if you want to continue processing.
 Note
A BAdI method is provided in the cession calculation function that you can use in a customer-specific
implementation to fill the cession rule and the portfolio treaty.
Explicit Retention
If you have explicitly defined a retention in the reinsurance program, this amount is assigned to the cession
group as applied retention and the unplaced risk is reduced.
Additional Retention
You define a threshold value for the additional retention. This is the maximum amount of the unplaced risk that
can be transferred to the additional retention of the cession group.
4.5.3.3.2 Risk Classes for Cession Calculation
Use
You use class models to subdivide risks into certain classes and to reinsure them differently, depending on the
class they are in.

Prerequisites
To work with classes, you must first define a class model with these classes in Customizing. For more
information, see Class Model with Risk Classes [page 61].
Features
In the reinsurance program you can define the maximum liability for a quota share or the retention for a surplus
treaty differently for each risk class. The cession calculation run uses the class-specific data in the reinsurance
program to distribute the risk accordingly.
Example
Structure
Assume you have defined the following risk classes for oil tankers: A: double-walled, constructed after 1996; B:
double-walled, constructed before 1996; C: single-walled. Your reinsurance program for the class of business
"Oil Tankers" is structured as follows: Reinsurance Program
If the risk exceeds the available capacity, you conclude individual facultative treaties.
Calculation
You have a cession group for a participation in an oil tanker insurance policy. The ship is a single-walled tanker,
so the cession calculation function selects the highest risk category, C. The cession calculation function can
find the correct class only if you have specified the Extension Service in the cession group and assigned this
combination of Extension Service fields to the class C in Customizing.
4.5.4 Business Involving Several Group Companies
Use
The functions described here enable you to map retrocessions within a corporate group, such as retrocessions
made by a subsidiary to the parent. They also allow you to handle risks assumed by two different companies
within the group as accumulations.

Process
These functions are based on the standard Risk Manager processes. When you map business involving several
group companies, the only aspects that differ are the handling for company codes and the use of specific
participation types.
Chain of Company Codes
Company code chains define the “paths” along which risks can be ceded within your group. They prevent
circular references for the coverages, and avoid illogical constructions, such as accumulations containing two
participations that follow on from one another.
For more information, see Chain of Company Codes [page 101].
Retrocession Within a Group
The system supports retrocession within a group by enabling you to create participations that can be used
both as assumed participations and ceded participations (connecting participations). You either create
connecting participations manually and assign a corresponding facultative connecting treaty or you include the
obligatory connecting treaty in the reinsurance program and let the system create the connecting participation
as part of the cession calculation [page 95] function.
You can also process accounts across companies.
Cross-Company Accumulations
You can treat policies that have been signed by two different subsidiaries as one accumulation.
For more information, see Accumulations Involving Several Group Companies [page 105].
4.5.4.1 Chain of Company Codes
Definition
The chain of company codes maps the sequence of the participations within a group. Preceding participations
by cedents outside the group and subsequent participations by third-party reinsurers are not affected.
You must assign a chain of company codes to each policy.
You can group original policies in an accumulation only if they have been assigned the same chain of company
codes. It is not possible to have a mixture of chains under an accumulation group.
Use
The chain of company codes for the policy defines which company codes can create participations, and the
order in which they can do so. If the policy itself was issued within the group, you must create it in a company
code at the first level of a chain of company codes.

Structure
A chain of company codes comprises one or more company code levels. To each company code level you
assign the company codes that can be used at that level. One of these company codes for each level is marked
as the central company code.
Company codes that have already been used must not be entered more than once in a chain of company
codes.
Integration
Company code chains affect the Risk Manager components in the following way.
Participations
● Participations outside the group

Participations outside the group that are used for information only are stored in the company code of the
policy or accumulation.
● Assumed participations within the group, first company code level
Participations within the group at the first level in the company code chain are created in the company
code.
● Assumed participations within the group, higher company code levels
These participations are assigned to a connecting treaty They represent ceded participations for the
previous participating company code and are in the central company code for the corresponding level.
● Ceded participations
The ceded participations for a given company code level are assigned to the company code of the cession
group that is linked to the ceded participation. This applies to ceded participations created by the cession
calculation function or created manually.
Portfolio Treaty
The risk carrier for the participation must be defined either the cedent or co-cedent of the assigned portfolio
treaty.
Groups
All groups up to the first level of the company code chain are assigned to the company code for the policy.
Accumulation Group
Policies in the same accumulation group must be assigned to the same chain of company codes.
Cession Group or Prior Cession Group
A cession group or prior cession group can contain participations from various company codes in a company
code level. The portfolio treaties used for the participations control how these participations can be grouped
into cession groups within a given company code level.
Cession groups that group policy sections or participations outside the group are assigned to the company
code for the policy.
Cession groups or prior cession groups that group participations within the group are assigned to the central
company code for the respective company code level.

The participations in a cession group or prior cession group have the same company code level, but may
belong to different company codes within this level. These participations must still be assigned to the same
portfolio treaty.
When you assign a status marked as “Closed” to a cession group the system assumes that you have finished
processing a company code. You cannot make any further changes.
The system provides the same status to the preceding participation and the subsequent obligatory
participation, as well as to the policy sections, coverages, and values insured.
 Note
The system does not automatically propagate a Closed status supplied by a BAPI during “Cross-Company
Code Processing”. You have to ensure that the “Closed” status is correctly assigned to the necessary
business objects otherwise the system ends the process with an error message. This may mean that you
have to adjust the interface connection, particularly if the BAPI is supplying partial statuses.
Cession Group Creation and Cession Calculation
You can execute the functions for creating cession groups and calculating cessions separately for each
company code level.
● The Cession Group Creation function creates a cession group for each matching portfolio treaty section
within a company code level. It only includes the participations in a level in the chain of company codes.
● The Cession Calculation function determines whether the assumed liability can be covered by the treaties
defined in the reinsurance program. It considers all the company codes within the company code level. The
function then creates a ceded participation for each treaty in the reinsurance program. The company code
of the ceded participation is taken from the cession group to which the ceded participation belongs. This is
the central company code of the preceding company code level.
Account
● The inward account is given the company code of the treaty assigned by the participation.
● Accounts generated by the Transfer to Basic System function take the company code from the
corresponding inward account.
● Accounts generated by the Transfer to Re/Retro function are given the company code of the treaty
assigned by the participation.
● The outward accounts for a connecting treaty are the basis for creating the inward accounts in the next
company code using the Transfer to Basic System function.
4.5.4.2 Retrocession Within a Group Using Connecting

Participations
If one group company follows another in the participation chain, and the reinsuring company code assumes
100% of the risk of the ceding company code, you can use a single participation to map the ceded business
side of the first company and the assumed business side of the other. You either create this participation
manually and assign a corresponding facultative connecting treaty or you include the obligatory connecting
treaty in the reinsurance program and let the system create the connecting participation as part of the cession
calculation [page 95] function.
For more information about the automatic generation of connecting participations, see Obligatory Connecting
Treaties in the Reinsurance Program [page 104].

Connecting Treaty
Connecting treaties link two companies within a corporate group that both work with the same client, but have
different company codes. One company participates in the reinsurance business of the other, either in one
direction only, or in both directions. A connecting treaty “hangs” between two company codes and supports
functions for the cedent and the reinsurer to map to the agreement between the two companies. You create
connecting treaties in Basic System. If you use a connecting treaty, the system automatically forwards
accounts from the first company code to the second.
For more information, see Connecting Treaty [page 199].
4.5.4.3 Obligatory Connecting Treaties in the Reinsurance

Program
Use
The use of an obligatory connecting treaty [page 199] in a reinsurance program [page 690] enables you to
map retrocession within a group.
More specifically, the Create Assumed Business Side in Risk Manager checkbox controls the generation of a
connecting participation when you define a treaty.
Prerequisites
A ceded, obligatory non-life treaty is defined by the following requirements:
● The Account Transfer from RM checkbox has been set in the treaty header.
● The Create Assumed Business Side in Risk Manager checkbox has also been set in the treaty header.
● Only one reinsurer participates in the treaty.
● The reinsurer, who is the owner company with a company code that is different to that of the treaty header,
is continuously 100% involved in all periods and sections.
● The Generate Inward Account checkbox has been set for the reinsurer's involvement.
You include this connecting treaty when you define a rank in a reinsurance program.
Features
Cession Calculation
If you have entered a ceded, obligatory connecting treaty in a reinsurance program for which the Create
Assumed Business Side in Risk Manager checkbox has been set, the system generates the corresponding level
in the chain of company codes when it calculates the cessions [page 95] for an obligatory connecting
participation.

In the standard system, this participation is assigned the cession rule “No Cession” and is not assigned a
portfolio treaty. You can change this manually online or using a BAPI. This means that the participation can be
processed by other subsequent processes (specifically the cession group creation function). A BAdI method is
provided in the cession calculation function that you can use in a customer-specific implementation to fill the
cession rule and the portfolio treaty. This ensures that the system continues to process the obligatory
connecting participation without further manual action from the user.
Account
If you trigger the Transfer to Basic System in Risk Manager Non-Life for a ceded account of a connecting treaty,
the system creates the related assumed account in the next company code in Risk Manager Non-Life.
This is, however, not the case if the ceded account of the obligatory connecting treaty is created directly in
Basic System. In this case, the related assumed account is created in Basic System when you release the
ceded account.
 Note
Only one obligatory connecting treaty is permitted for each validity period of a reinsurance program.
You cannot enter obligatory connecting treaties when you create a participation manually.
Obligatory connecting participations are not supported in primary insurance accumulations.
4.5.4.4 Accumulations Involving Several Group Companies
Use
In order to monitor how risks are distributed, not only within individual companies but also within the corporate
group as a whole, you can group policies involving different group companies as accumulations.
Prerequisites
● The original policies to be grouped in an accumulation must have the same chain of company codes (and
therefore the same central company code).
● The accumulation group is assigned to the central company code of the chain of company codes.
● All groups except for cession groups and prior cession groups are assigned to this central company code.
Features
Accumulation Control
The accumulation control [page 84] function regards accumulations in other company codes that fulfill the
above prerequisites as equal to accumulations in the same company code.

Joint Retrocession of Accumulated Liabilities
The functions for cession group creation and cession calculation can also process aggregated liabilities
originating from different company codes. To do this, these liabilities must be grouped in the same
participation on the assumed business side.
Separate Retrocession for Each Company Code
If you want to create an accumulation group across several company codes, but do not want to create joint
retrocessions for the shares of these company codes, you can control this by using separate participations.
4.5.5 Participation
Definition
A participation is the reinsurer's share or your own retention in a certain cession group created for an original
policy section or another participation.
Use
You can use participations to map the share of one of your own companies in a given risk, your own retention,
or the shares of your cedents and reinsurers. These different usages for participations are represented in the
system by participation types.
You can recognize the position of a participation in a chain of participations by looking at the context of the
assumed and ceded groups on either side of the participation, and by looking at the position in the company
code chain.
The participation has two formats. In contrast to the current format, the newer, more flexible format provides
the user with more options to specifically reference a liability extract. It also allows the user to merge
proportional and non-proportional treaties in a cession group period and arrange these in a hierarchy. The
format of participations that are created automatically by cession calculation is based on the assigned
reinsurance program period. The format of manually created participations is based on the participations that
already exist in the cession group period. New periods for manual groups and prior cession groups are
assigned participations with the new format.
In order to specify the relevant liability extract of a participation (the liability amount that represents the
calculation base of the participation), you must enter a coverage reference for the participations that have a
flexible format.
The following coverage references are available:
● TOTLB – total liability of reference rank

● RETEN – retention of reference rank
● XSAMT – excess amount of reference rank
● UNCSR – uncovered share of reference rank (total of RETEN + XSAMT)
● UPRSK – remaining unplaced risk that exists based on the reference rank
Participations in the current format always refer to the total liability.

You can also structure the retention in a more flexible format. Here you have the following options:
● RIPRA – transfer the retention to the applied retention

● IGNOR – retention is not included
● PREV – retention is already covered by previous ranks
● SUBSQ – retention is covered by subsequent ranks
The retention in participations in the current format is always transferred to the unplaced risk.
Constraints
The entries are validated as follows:
● The coverage reference TOTLB can be entered only if the reference rank is 0.
● The coverage references RETEN, XSAMT, and UNCSR can be entered only if the reference rank is not 0.
● The retention control IGNOR is not permitted in a non-proportional participation.
● If the reference rank does not equal 0, the values that can be entered for a coverage reference depend on
the settings made to control retention in the reference rank. For example, the coverage reference for a
participation cannot be used to refer to the retention in participation if this coverage reference transfers
the retention to the applied retention. The use of the reference rank 0 implies that the coverage reference
TOTLB has been entered.
Structure
Assumed Business
The Policy Section Overview tab page shows the policy sections covered by the participation and the preceding
group to which the participation is linked. You can also display this data in the liability overview for the cession
group.
Ceded Business
The Participation Grouping tab page shows the shares of the risk ceded to other participations (via cession
groups). You can also display this data in the liability overview for the cession group.
Structural Characteristics, Splits, and Exclusions
The system determines the relevant structural characteristics for the participation on the basis of the
characteristics for the assigned policy section (adjusted for any exclusions for the policy section),
the characteristics for the participations between the policy section and the participation being evaluated, and
the characteristics for the participation itself.
The coverage scope of a ceded participation of a carve-out cession group is the subset of:
● The structural characteristics of the logical policy sections or participations minus the exclusions defined
for the assumed and ceded participations
● The structural characteristics of the assigned ceded master treaties minus the exclusions defined for the
treaty
 Note
The treaty details determine the coverage scope of the participation.
For more information, see

● Structural Characteristics and Splits in Policy Sections and Participations [page 131]
● Exclusion of Structural Characteristics/Combinations in a Policy Section or Participation [page 132]
Totals and Premiums
Total Liability
The total liability covered by a participation is calculated on the basis of the direct or indirect share in the
original policy section covered by the participation. You see the liability totals on the Participation Data tab
page. For more information about how the total liability is calculated, see Liability Aggregation [page 75].
LUD
In the case of a non-proportional participation, you can enter the deductible and liability of an assigned
facultative treaty. If an obligatory treaty is assigned to the participation, the system takes these entries from
the treaty.
Premiums
For more information about the calculation of premiums, premium schedules, and reinstatement, see:
● Participation Premium [page 109]

● Premium Schedule [page 109]
● Reinstatement Schedule [page 111]
● Determination of Expected Premium [page 111]
● Premium Payment Warranty [page 112]
References
You can assign external references that apply across all periods and period-specific customer references to a
participation. You can use both types of references to search for participations.
References That Apply Across All Periods
You enter external references that apply across all periods in the corresponding table.
Field Meaning
External reference category You enter an external reference category in this field. You de
fine the available categories in Customizing under FS-RI
Reinsurance FS-RI:Risk Manager (Non-Life)
Participation Management Edit External Reference
Categories for Participations .
External reference ID This field contains the actual reference ID. When you create
an external reference, you enter the external reference cate
gory and double-click the table row. You can then enter the
reference ID.
Partner This field identifies the business partner supplying the exter
nal reference.
Period-Specific References

You enter period-specific customer references in the field of the same name in the participation data. The
system does not check whether these customer references are unique. The entries are converted to upper
case.
Account Totals
You can view the current account totals for the participation on the “Account Totals” tab page.
4.5.5.1 Participation Premium
Definition
The premium for a participation stipulates the premium paid for the liability assumed by the participation.
Use
You can enter the participation premium manually in the premium schedule, or define it by entering a premium
or liability percentage.
The premium percentage is an optional entry and provides an alternative method of distributing the premium
to the loss. This field is provided for proportional and non-proportional participations as a value type in the
participation date. For ceded participations, this field is provided in the liability overview for the cession group.
If you do not enter specific premium data, the system uses the loss distribution percentage in the proportional
area to calculate premiums.
4.5.5.1.1 Premium Schedule
Definition
On the Premium Schedule tab page, you can map the linear and non-linear premium developments for a
participation.
Use
When you create and change participations, you can create premium schedules on this tab page and, if
necessary, change or delete and reverse them later.
In the background the system supports you with functions for adjusting the pro rata amounts automatically
(depending on the premium category) and for creating premium installments.

The system posts the premium schedules either using the Create Accounts for Premium Schedule background
job or when you confirm the policy or accumulation that belongs to the participation with a status that allows
posting and is not reversed. However, you must have set the participation to “Create Postings”.
If you want to create accounts for premium schedules as soon as you confirm a policy or accumulation, you
have to set the Create Accounts for Premium Schedule checkbox for the participation. This does not apply to
participations for information purposes, participations with the category “Retention”, and participations that
are assigned P2R cession groups.
You can trigger the Confirm function online and in the RM Combined Background Job and Risk Manager
Adjustment After Changes in Basic System background jobs. You can also have the system trigger this using the
Confirm API for a reinsured policy.
It is no longer necessary to run the Create Accounts for Premium Schedule background job for this type of
participation. You have to enter the technical data needed to execute the immediate creation of accounts for
premiums with regard to the specified time limit and the processing scope of the accounts in the Customizing
activity Edit Defaults for Premium Schedule.
You need a distribution plan to clear a premium schedule. This distribution plan is generated automatically
when you create the premium schedule provided the structural characteristics of the related policy sections
each have a single unique entry that is not a hierarchical node. The resulting distribution plan consists of a
100% entry. Existing distribution plans are not regenerated.
Similarly, distributions are not generated if you can select more than one company code for ceded
participations or connecting participations or if there is no master treaty in the participations.
If you have selected the accounting mode Occurrence Year for the participation, the system generates a
distribution plan for the participation. If you have selected the accounting mode Underwriting Year, the system
generates a distribution plan for each underwriting date.
When you reverse a premium schedule, you can enter a reversal reason. This reason is then used as the name
of any resulting accounts and is displayed on the screen for the premium schedule.
Structure
Switch to the “Premium Schedule” tab page at participation header level. Here you enter the total premium
amount, the premium category, and the term of the premium.
If a premium schedule applies to a specific treaty term or period, the system proposes the values from the
current participation period as the start and end dates. In a premium schedule for a specific period, the system
also determines a default value for the premium reference period from the Customizing activity Edit Defaults
for Premium Schedule.
You double-click an entry to call the details of the premium schedule installments. You can distribute the pro
rata premium amount that has been calculated by the system in the premium schedule header across the
various due dates, either as absolute amounts or on a percentage basis. The due date can lie outside the
validity period of the participation.
In this case, premium schedule installments can be generated with accounting periods that lie outside the
validity of the participation, which means that the system displays error messages resulting from the checks
from the Customizing activity Edit Account Validation Checks. You can deactivate these checks in this
Customizing activity or you have to adjust the accounting periods of the individual installments.

You can enter an informative description for each individual installment of a premium schedule. This
description is then copied to the account that is created. You can use these individual descriptions to identify
the accounts for a premium schedule that were created automatically.
To get a better overview of the installments of a schedule for one-time premiums, the system displays the
period in which the premium schedule installments are cleared.
4.5.5.1.2 Reinstatement Schedule
Use
In non-proportional business, the reinsurer is liable for a specific loss amount defined by the layer. In return for
assuming this risk, the reinsurer receives a premium, which is negotiated between the cedent and reinsurer.
The reinstatement schedule defines how the partners involved proceed if the entire loss amount is used up. It
specifies the reinstatement premium the cedent has to pay if it wants the reinsurer to renew its cover.
You can create reinstatement schedules only for non-proportional treaty sections that allow reinstatement and
for which a corresponding limit has been set in the premium and liability data.
Features
You can only enter reinstatements for participation for information purposes. They are not processed further
by system functions.
4.5.5.1.3 Determination of Expected Premium
Use
In addition to the premiums defined in the premium schedule at participation level, you can enter premiums on
the “Participation Data” tab page using value types. These are referred to as expected premiums.
Prerequisites
The system posts the defined expected premiums automatically under the following conditions:
● An entry code must be assigned to the value type for the premium.
● The “Create Postings” checkbox must be set at participation header level.
● The participation and superior object (policy or accumulation) must have a status that allows posting and
is not reversed.

Activities
On the Participation Data tab page you can enter an expected premium as a value type under “Statistics/
Values”.
The premium category controls whether the expected premium is a one-time premium, or whether it applies to
a specific period or contract term.
Set the “Create Postings” checkbox.
If the processing is complete for the participation, the related objects and the superior object (policy or
accumulation), confirm the superior object and set it to a status that allows posting and is not reversed.
When you save, the system creates the postings for the expected premiums automatically.
4.5.5.1.4 Premium Payment Warranty
Use
When you assume business, you use this function to stop the system making payouts for losses if the premium
payments for a participation are not received by the stipulated date.
When you cede business, you use this function to monitor whether you have paid all the premiums for a
participation on time to ensure that you do not lose coverage.
Prerequisites
● You must define premium schedule installments with payment warranty deadlines for the participation.
● You must assign a unique main transaction or subtransaction for generating the payment plan items in the
FS-CD system to the premium entry code in Customizing.
● The Itemization in Current Account Statement checkbox must be set on the Participation Data tab page.
● You must define how the system should react if the premium payment warranty is violated. You do this in
Customizing for FS-RI Risk Manager (Non-Life) under Default Values Edit Defaults for Accounting .
There are two possible responses: No more accounts are transferred to Basic System (this then applies to
all accounts, for both premiums and losses) or a warning message appears but the accounting functions
are executed in the normal way.
Features
The premium payment warranty ensures that premiums are no longer considered if they are received later than
the due date plus the grace period for the premium payment guarantee. When you use the function for ceded
business, you receive a warning before the guarantee period expires.
Check for Assumed and Ceded Business

When you transfer an account to Basic System, the system checks whether the premium payment was posted
in the current account system in time.
Reaction If Deadline Is Not Met
If the payment was not made on time, the system can respond in two ways, depending on the Customizing
setting:
● It displays a warning.
● It stops the transfer of the corresponding account to Basic System.
Additional Check for Ceded Business
You can monitor upcoming due dates for ceded business using the Check Compliance with Premium Payment
Warranty [page 553] background job.
Constraints
● The premium payment warranty is available in Risk Manager only in conjunction with the premium
schedule – if no installments have been defined for a premium schedule, you cannot define a deadline for
the premium payment warranty.
● Expected premiums generated automatically on the basis of value types are not included in the checks,
since no deadlines can be defined for these premiums.
● The premium payment warranty function can only be used in conjunction with the FS-CD application. It is
not supported in for FS-AR.
● The field for the underwriting date is not used in the FS-CD system. This means that the FS-CD system
cannot be used to check payment for a specific underwriting date.
● In the following special case, you must postprocess the data manually in the FS-CD system: Assume that
an account has been created for three installments from the premium schedule, and that the
corresponding postings have been transferred to the FS-CD system with three different due dates. This
creates three open items in the FS-CD system. The first payment is settled within the premium payment
warranty period, the second payment is made, but not within this period, and the third payment is also
settled within this period. In this case, the conditions for the transfer to Basic System would not be fulfilled,
since not all the open items were settled within the required period. To transfer the account to Basic
System, the user would have to go into the FS-CD system and change the clearing date of the second open
item manually.
● Only fully cleared open items count as cleared. Partially cleared items are not included.
4.5.5.2 Result-Independent Condition
Definition
The validity and effects of result-independent conditions for a participation are independent of the premium
and loss development. Examples include result-dependent commission payments or a reinsurance tax with a
fixed percentage rate.

Use
● Management of reserves
● Portfolio entry and portfolio withdrawal
● Unearned premiums
● Result-independent commission payments
● Stopping or transferring specific entry codes (either partly or entirely)
Structure
For more information about the Result-Independent Conditions screen, see the documentation for Basic
System entitled Result-Independent Condition [page 114].
Validity Period
If you create a new condition of the same type, but with a different valid-from date, the system sets the valid-to
date of the previous condition to the valid-from date of the new condition. A condition is “of the same type” if
the category, rank, target entry code and usage are the same. All the other fields can differ between validity
periods.
The system performs validation checks to ensure that the validity periods for conditions of the same type do
not overlap. It also checks that the valid-to date for a condition is after the valid-from date, and that the valid-
from date is not blank if a value has been entered in the Valid-To field. The same applies if changes are made to
the validity periods in retrospect: the system always ensures that conditions of the same type do not have
overlapping validity periods, and that there are no gaps between the validity periods.
Minimum and Maximum Condition Amount
You can enter a maximum and minimum condition amount for each condition. These entries set an upper and
lower limit for the amount that is calculated for the condition. Therefore, the following applies: “minimum” <=
calculated condition amount <= “maximum”. However, these limits are for information only, and are not
processed by the system.
Integration
If you make changes to conditions after postings have already been made (as would be the case with short-
term cancellation), you can correct the postings by running the background adjustment job.
4.5.5.3 Result-Independent Condition
Definition
A condition whose validity and effect does not depend on the premium and loss development of the treaty.
Examples include a result-independent commission or a reinsurance tax with a fixed percentage rate.

Use
You use result-independent conditions in the following cases:
 Note
A separate function is provided for the management of funds. For more information, see Funds [page 260].
Structure
Edit
The result-independent conditions are displayed at period, partner involved, and section level. However, you
can enter data at period level only. This enables you to define result-independent conditions globally for all the
sections and partners involved.
Condition Templates
If you use template groups, you do not have to enter frequently occurring conditions individually for each
treaty. Based on the group characteristics, you can create multiple templates for conditions that occur
together in a template group (such as portfolio entry and portfolio withdrawal) and load these in the treaty.
Create
You define templates for result-independent conditions in the initial menu under Basic System Treaty
Templates Result-Independent Condition Groups . The template has the same structure as a condition in a
treaty, except you cannot enter data that depends on the treaty, such as section, share, and comments.
Use
You load condition templates into the treaty by choosing the pushbutton. You can then edit the condition as
required for a specific treaty.
Layout
The type and exact value of a condition is determined by the condition category. You use the usage of a
condition to define when the system calculates the condition. Since dependencies can exist between
conditions, you must always enter a rank. After you have entered the condition category and rank, the system
opens the fields in the table relevant for the condition category. For more information, see Condition Categories
[page 234].
Area of Application
You can restrict the area of application of a condition to a specified section, partner involved, or accounting
unit.

Integration
Automatic Adjustment
If a treaty is cancelled or changed under certain circumstances (for example, at short notice), the system
recalculates the conditions.
The system checks whether conditions need to be recalculated when you set the status of the period to
“Posting Allowed” and “Canceled”, or “Posting Allowed” and “Not Canceled”, and save the treaty. The system
starts recalculating each condition according to the combination of accounting time and change reason you
have defined in Customizing for Basic System under Treaty Conditions Edit Combination of Change
Reason and Time of Accounting .
Determination of Processing Sequence If Fund Exists
If you have entered at least one fund in addition to result-independent conditions, the system determines the
total number of tasks to be processed based on the conditions and fund-related activities. It compiles a
“mixed” processing sequence based on the ranks assigned to these tasks. For more information about the
order in which funds and result-independent conditions are processed, see Funds Retained and Release of
Funds [page 261].
4.5.5.4 Result-Dependent Condition
You can define result-dependent conditions in Risk Manager for information purposes. The system does not
process this data automatically. In other words, if such a condition requires a posting, you must create the
posting manually.
The structure of result-dependent conditions matches the structure in Basic System [page 215]. As in Basic
System, you can also define sliding scales. Templates are not supported.
4.5.5.5 Pro Rata Temporis Distribution
When participations have a fixed underwriting year, the system distinguishes between those with a fixed liability
and those with a variable liability. The distribution of premiums on a pro rata basis is not allowed for
participations with a variable liability, but is allowed for participations with a fixed liability. The following section
explains the effects of setting the No PRT Distribution checkbox, which depend on whether processing is
carried out manually or automatically.
Automatic Processing
If the Processing Interface (PI) attempts to confirm a policy or accumulation that contains a participation with
the setting No PRT Distribution automatically, the system terminates processing and displays an error
message, irrespective of whether or not a cession was changed. Manual confirmation by the user is required.
For more information, see Risk Manager Combined Background Job [page 525].

Manual Processing
If the user confirms a policy or accumulation that contains a participation with the setting “No PRT
Distribution”, and for which a cession has changed, the system checks whether the postings for each revenue
period amount to zero. If this is not the case, the system terminates the process with an error message and the
postings have to be corrected manually. The accounting function checks the existing postings when you save
the policy or accumulation after changing the status.
4.5.5.6 Status Control
Use
The status plays a key role when you edit policies, groups, and participations, or create accounts for these. The
status also controls the generation of complete historical statuses for policies and accumulations.
Statuses Open for Posting
If the status of a journal entry has the attribute Posting Allowed or Complete, you cannot edit the data for the
corresponding period.
A status with the attribute Posting Allowed can be set from the superior object only. Account postings can be
created only for objects with statuses that are open for posting.
You can use the background job Generate Complete History (/MSG/H_H_HISTORY_ASSEMBLER) to generate a
complete history, including all assigned objects, for the most recent status of a policy or accumulation that is
open for posting.
Features
Status Propagation
When the status of an object changes, the system also changes the status of dependent objects when you
perform the following activities:
● Cession group creation

● Reversal with calculation of returns
● Reversal without calculation of returns (restricted)
The system always uses the statuses defined in Customizing under FS-RI:Risk Manager (Non-Life) RM
Functions .
Status Change
You can change a status at policy and accumulation level only by choosing Confirm. The following rules apply:
● The status Posting Allowed/Not Reversed can be set only in the superior object by choosing Confirm.
● The status that allows posting is forwarded to all the assigned technical objects provided these objects do
not already have a reversed status.

● If a policy that is open for posting or an accumulation is set to "In Process" by choosing Confirm, then this
status is also forwarded to only those assigned technical objects that have not been reversed.
● Similarly, you can set the status Reversed only by choosing Confirm. This status is not forwarded to
assigned technical objects if these have already been reversed.
● You can also set the status Reversed in lower-level objects using the Status Change function.
● Part of the policy period is assigned to an accumulation. Both the policy and accumulation are in process. If
the policy is not confirmed with the status Posting Allowed/Not Reversed, then the status of the policy
header remains set to In Process.
You can change the status of the lower-level objects for a policy or an accumulation using the Status Change
function. The following rules apply:
● The status Posting Allowed/Not Reversed cannot be set using the Status Change function.
● Status changes at policy section level must always be propagated.
Check
The Functions Checked checkbox can be set for a status. If this checkbox is set for a status, the system runs
validation checks when this particular status is set.
Generation of Histories
You can use the Generate Complete History background job to synchronize the delta histories of a policy or an
accumulation into complete histories. When you use this job, a complete history, including all assigned objects,
is generated for the most recent status of a policy or accumulation that is open for posting.
If the policy or accumulation has never had a status that allows posting, then the complete history contains the
current operational data.
4.5.5.7 Generation of Histories in Risk Manager Non-Life
Use
The history documents the changes made to the policy or accumulation.
Prerequisites
A delta history is generated for the policy or accumulation each time data is saved. The background job /MSG/
H_H_HISTORY_ASSEMBLER is provided for grouping delta histories into complete histories.
Features
A delta history contains the changed data of the policy or accumulation between two save operations.
It documents the changes made to a policy or accumulation.

A complete history groups the delta histories of a policy or accumulation into a single historical status. The
delta histories are not deleted.
The system generates the complete history, including all the assigned objects, for the most recent status of a
policy or accumulation and includes this history after the status of the policy or accumulation that is open for
posting. If the policy or accumulation has never had a status that allows posting, then the complete history
contains the current operational data.
The complete history of an accumulation contains all the policies that have ever been assigned to it. Regardless
of the assignment period, the entire policy and all its periods are included in the complete history.
If one of the policies is assigned to another accumulation, then the system generates a complete historical
status, including all the assigned objects, for this accumulation. This means that all the objects that have ever
been related have the same complete historical status.
Result
In addition to the delta histories created by save operations, the history also contains the complete histories
generated by the background job /MSG/H_H_HISTORY_ASSEMBLER.
 Note
Using the complete historical statuses you can run the background job /MSG/H_H_HISTORY_UNDERTAKER
to delete the combined delta histories. When you do so, you can select whether all delta historical statuses
older than the most recent complete historical status are deleted for an object or whether only the delta
historical statuses before the first complete historical status are deleted.
In this way, you can reduce the number of historical statuses created for Risk Manager in-force business
data.
The complete historical statuses and the delta histories generated after the last complete historical status are
sufficient to ensure that the accounting functions work correctly.
A pushbutton for activating the history mode is available in the toolbar on the screens used to manage
portfolios. You can select the required entry from a list of available historical statuses.
4.5.5.8 Creating Cession Groups and Participations
Prerequisites
You have created the participations you want to group and for which you want to create a new participation.
Context
This procedure describes how to create a cession group for an existing participation. This cession group can
then be used to create a participation in the existing participation.

Constraints
You cannot create a direct link between two participations without using a group in between. This means that
you still have to create a group even if you only want to link one participation to another.
Procedure
1. At policy level, switch to the Participation Grouping tab page.

2. In the Assumed Participations table, select the participations for which you want to create a group. If you
want to create additional participations for an existing cession group, you can navigate to the liability
overview of the cession group instead of performing steps 1 and 2.
3. Select Group/Participation.
4. Enter all the required data in the dialog box. Choose a group category with the type “Cession Group” and
the level “Journal”, such as the group category “Cession with Journal”. In the first row of the Participation
Data section, specify whether you want to create a participation for the group at the same time, or whether
you want to assign an existing participation. After you have entered the participation category, the system
displays the relevant input fields. Participations with the category “Retention” are created by cession
calculation only and cannot be created manually. If these are participations for an automatic cession
group, you must enter the participations in accordance with the format of the reinsurance program [page
690]. Otherwise, the participation format is based on the existing participations in the cession group
period; if the cession group period is new, only the flexible participation format is supported.
5. Confirm the entries you have made in the dialog box.
4.5.5.9 Assigning Master Treaties
Use
All participations that relate to your own company must be assigned to a master treaty. You assign assumed
participations to assumed master treaties, and ceded participations to ceded master treaties.
Participations with the category “Retention” that cannot be assigned to a master treaty are an exception
among the ceded participations.
Prerequisites
The structural characteristics of the master treaty must cover those of the participation header.
If the Carve-Out checkbox has been set, the coverage scope of the master treaty must cover at least a
combination of the structural characteristics of the participation header.

Procedure
Assigning to an Existing Treaty
1. Open the participation.

2. Switch to the Participation Data tab page, and enter the treaty assuming the risk under Participation
Header. You can also search for treaties that match the structure of the participation header using the
corresponding pushbutton.
Creating a New Treaty
1. Open the participation.

2. Create a master treaty.
For more information, see the documentation for Basic System [page 194].
4.5.5.10 Reversal of Participation Periods
Use
You can use this function to reverse postings made for a participation period.
You can also partially reverse postings and prevent further postings.
Features
You reverse a participation by setting the participation to a status with the attribute Reversed.
The nature of the reversal depends on the other status attributes.
 Recommendation
We recommend that you define the following reversal statuses in Customizing:
1. Reversal with Recalculation, Posting Not Allowed

If you set this reversal status, the system rolls back postings that have already reached the reinsurer for
the reversal period in question. In other words, it is always the postings on the ceded business side that
are reversed. The supplement “Posting Not Allowed” indicates that no more postings are permitted on
the assumed business side for periods that have already been reversed.
2. Reversal with Recalculation, Posting Allowed
If you assign this status, any existing postings on the retrocession side are rolled back, as in point 1.
However, in contrast to point 1, new postings may be created on the assumed business side for the
reversed time period. These postings are no longer transferred to the retrocession side.
3. Reversal Without Recalculation, Posting Not Allowed
This status means that existing postings for the time period being reversed are no longer rolled back.
All the funds that have been posted to the reinsurer are left with the reinsurer. The supplement
“Posting Not Allowed” indicates that no further postings are permitted in the time period being
reversed.

4. Reversal, Posting Allowed, Returns Not Calculated
This status only differs from point 3 in that postings can be created again for the corresponding time
period on the assumed business side.
If the period on the assumed business side had a status open for posting at some point in the past, the
system also creates a reversal group (see Creation of Reversal Groups [page 123]). When the reversal
group is created, the system deletes the reference to the cession group creates a new reference to the
reversal group. A reversal group is a copy of the cession group and reflects the status of the cession
group when posting was last permitted for the related superior object (accumulation group or policy).
Any new postings entered on the assumed business side (premium postings only) can be transferred to the
retrocession side, and are assigned to the policy sections that are linked to the reversal groups. This allows you
correct premiums that have been posted to accounts in advance.
Activities
1. In the superior object for the participation chain (policy or accumulation group), choose Change Status and
select a reversal status.
2. The system performs the reversal as defined by the attributes of the selected reversal status.
3. Execute the retrocession adjustment [page 172] to ensure that the accounts are adjusted correctly.
4.5.5.10.1 Short-Term Cancellation of a Participation
Use
You use this function to reverse participation periods for which premiums have already been posted. It allows
you to calculate the corresponding penalty for the cancellation.
Prerequisites
● You must define a status for short-term cancellation with the change reason “Short-Term Cancellation” and
the attributes Reversal and Posting Allowed.
● Premiums to be reimbursed automatically must have been created by the Determination of Expected
Premium [page 111] or the Premium Schedule [page 109] function. (Premiums created manually are
excluded from the automatic adjustments.)
● You must define the portion of the premium to withheld (penalty) as a result-independent condition [page
231]. This condition must have the portfolio rule accounting time “Short-Term Cancellation” and the
category “Other”. The system posts part of the premium amount for the reversed period to a different
entry code (such as “Penalty”).
● The Create Postings checkbox is set in the participation header.

Features
To map a short-term cancellation, you must set the status of the participation to a reversal status and enter
“Short-Term Cancellation” as the change reason.
The system then checks whether result-independent conditions have been defined with the relevant
accounting time, calculates the condition amounts, and creates the corresponding postings.
Activities
1. Call the participation and change the status to “In Process”.

2. Check whether a condition has been defined for short-term cancellation. If not, create the condition in the
master treaty or in the participation itself. For more information, see Result-Independent Condition [page
231] (for participations) and Result-Independent Condition [page 114] (for master treaties).
3. To change the status of the participation period relevant for the short-term cancellation to the status
defined for this purpose, choose the Status Change pushbutton and enter a reason for the change.
4. You can also opt to change the remainder of the participation period (to be reversed normally) to a reversal
status, but with a different change reason.
5. Confirm the superior object. For more information, see Status Control [page 72].
6. Upon confirmation the system recognizes that a condition has to be applied to a participation period that
has been set to the status “Short-Term Cancellation” (for example, to transfer 10% of the premium
reimbursement to a penalty entry code). It calculates the condition amounts and generates new accounts.
7. The system performs an adjustment run on the assumed business side to reverse all the premiums in the
affected period that were generated automatically.
8. It also adjusts the installments in the premium schedule accordingly.
Result
The superior object and its participations are confirmed and the short-term cancellation process is complete.
4.5.5.10.2 Creation of Reversal Groups
Use
If you assign the status “Reversal Without Calculation of Returns, Posting Allowed” to a participation (see
Reversal of Participation Periods [page 121]), the system removes the participation from any existing (prior)
cession group assignments. At the same time, it creates a new group with the category “Reversal Group” or
“Prior Reversal Group” and assigns the participations in accordance with the time periods being copied.
Features
Background Checks

The system runs a series of checks when it creates reversal groups:
● An assumed participation can have the status “Reversal Without Calculation of Returns, Posting Allowed”
only if its ceded side exclusively comprises participations that do not have LUDs.
● The system checks whether the group category "Prior Reversal Group" or "Reversal Group" is defined in
Customizing, depending on whether the group currently assigned is a cession group or prior cession
group.
● The system checks whether a subsequent status has been defined for the current status.
● The system checks whether a change reason has been specified for the current status.
● The system checks whether the Propagate checkbox has been set for the status “Reversal”.
● Participation assignments for a (prior) reversal group cannot be deleted manually.
Reactivation
You can reopen participation periods that are assigned to a reversal group (prior reversal group or reversal
group). To do so, you remove all participations whose status is no longer “Reversal Without Calculation of
Returns, Posting Allowed” from the associated reversal group by deleting or modifying the relevant
participation assignments. These participations are then available for processing. The change takes effect
when you save the data and before the cession group creation function is called. If the system finds
participation assignments for a reversal group that no longer has participation periods, it deletes them.
Activities
1. The periods to be copied are represented by the intersection of participation periods to be reversed and
the historical participation assignments to groups.
2. The system copies the ceded data for each group header and allocates new IDs. The data copied depends
on the participation period and the group assignment period.
3. This copy is used as the last active status of the group.
4. If you want to delete participation periods that extend beyond the last status allowing posting, the system
determines the data for the remainder of the period directly from the historical data.
5. The new group has the status "Posting Allowed".
4.5.5.10.3 Change in Reversal Status
The following examples illustrate how the system responds to status changes relating to a reversal.
In these examples, we assume that the user has set the wrong status by accident and wants to correct the
error by changing the status back again.
The description focuses on the effects of the change on the account.
 Note
Pay particular attention to examples 7 and 9 since you need to follow a special procedure here to produce
the correct results.
1. STORNB → STMRNB

The corresponding periods in the cession group are reversed, and the existing postings for the cession
group are adjusted.
2. STORNB → STMRB
As for example 1, but new postings are permitted.
3. STMRNB → STMRB
The postings are adjusted and new postings are permitted.
4. STMRB → STMRNB
As for example 3, but no new postings are permitted.
5. STORB → STMRNB
One or more reversal groups are created. When the status is changed, the postings are changed to
STMRNB.
6. STORB → STMRB
One or more reversal groups are created. When the status is changed, the postings are changed to
STMRNB and new postings are permitted.
7. STMRNB → STORNB
8. Initially, no changes are made, since postings were already reset in the first step (STMRNB). To make a
change: set the period on the assumed business side back to “Posting Allowed” (not reversed) and enter
any postings. Then set the status to STORNB, which gives you the results entered under STORNB above.
9. STMRB → STORB
As for example 7.
10. STORNB → STORB
To make a change: set the period on the assumed business side back to “Posting Allowed” (not reversed)
and enter any postings. Then set the status to STORB, which gives you the results entered under STORB
above.
11. STMR[N]B → STORB
As for example 9: The postings are adjusted.
12. STORB → STORNB
The reversal group is deleted.
4.5.6 Cession Group
Definition
A cession group is used to group participations, which can then be reinsured jointly. You need cession groups to
map participation chains, since a participation can reference only groups, and never policy sections or other
participations.
Use
Policy Section Group
The cession group can also group policy sections as opposed to participations. The first cession group in a
participation chain is always a policy section group.
Chain of Participations Before a Company's Own Participation

A cession group can contain any number of participations that belong to the same accumulation. These
participations may belong to one policy or several different policies.
 Recommendation
However, we recommend you create a separate group for each policy section or participation, since this is
the only way to create a participation chain and retrocession structure for a specific policy section. If you
group several policy sections or participations in a group, you are compelled to enter subsequent
participations further down the chain jointly for these policy sections or participations.
Creation of Cession Groups After a Company's Own Participation
The cession group creation function creates cession groups automatically.
The cession calculation run distributes the total amount defined for the cession groups and distributes this
amount to the ceded reinsurance treaties defined in the layers of the reinsurance program.
Prior Cession Group
Prior cession groups are a special form of cession group. For more information, see Prior Cession Group [page
127].
Creation of Cession Groups
For more information about creating cession groups, see Processing Cession Groups [page 129].
Structure
To be used as a cession group, a group must be assigned a group category with the level indicator Journal and
have the group type “Cession Group”.
Alternatively, you can use a group with the level indicator Cession. However, in this case you cannot restrict or
subdivide the validity period of the group because the group journals are not available.
Group Journals
The group journals (on the Group Journals tab page) subdivide the groups into different validity periods. These
periods are based on the validity periods for the assigned objects (policy sections, participations).
Participation Grouping/Policy Section Grouping
This tab page at group level contains all the data relating to the assumed business side of the group, including
the liability of the group and assumed participations.
 Note
There are no assumed participations for policy section groups.
Liability Overview
This tab page at group level contains all data relating to the assumed business side of the group.
This includes data about the assumed policy sections or assumed participations and the resulting liability to be
reinsured. You can select a group to be carved out (partial coverages).

The cession calculations data on this tab page includes the reinsurance program, alternative cession
calculation amounts for retention and surplus, and the date and time of the last cession calculation run.
This overview also shows how the liability is distributed to retention, ceded participations, and unplaced risk.
Example
For more information about the composition of cession groups generated by the cession group creation
function, see the general example in Retention and Ceded Business [page 90].
4.5.6.1 Prior Cession Group
Definition
Prior cessions are cessions you enter manually for an assumed risk before the risk is assigned to ceded treaties
automatically by the system.
Use
You can use prior cession to assign part of the assumed risk to any ceded facultative reinsurance treaty
manually before the remainder of the risk is assigned to matching ceded treaties by the cession group creation
and cession calculation functions.
This allows you to cover greater risks than you anticipated, to homogenize the reinsurance portfolio in the
treaties assigned automatically, or to take advantage of a cheaper reinsurance offer than that provided by the
automatically-assigned treaties.
You can assign several participations belonging to an original policy or accumulation group to a prior cession
group. If no accumulation group has been assigned, you can only assign participations to the same prior
cession group if they all have the same policy as the superior object.
The remaining liability used as the basis for cession calculation corresponds to the gross liability of the
assumed liability minus the liability covered by the prior cession group.
Structure
You define prior cessions in prior cession groups. A prior cession group is a special form of cession group
whereby the “Prior Cession Group” checkbox is active for the group category. You can assign prior cession
groups to treaties manually only. They cannot be used in reinsurance programs or by the cession calculation
function.

Prior cession groups can specifically reference a liability extract and can be arranged in a hierarchy (for more
information, see Participation [page 106]).
Integration
● A participation cannot be assigned to a prior cession group more than once for the same period.
● If you want to assign several participations from different policies to a prior cession group, they must all
belong to a matching accumulation group for the period in question.
Example
For an example of the process, see Example: Creating Cession Groups [page 188].
4.5.6.2 Manual Cessions
Prerequisites
You have assumed liability in an assumed participation.
Context
You can follow this procedure if you do not want to use the cession group creation and/or cession calculation
functions, or if the prerequisites for using these functions are not fulfilled.
There may also be cases where you need to create a separate cession group for a single participation journal
(for example, if the underwriting year is fixed and pro rata temporis distribution is not permitted).
Procedure
1. Creating a cession group and participation manually
To create a cession group and participation, see Creating Cession Groups and Participations [page 119].
Once you have created the group and participation in this way, you must assign the participation to a
reinsurance treaty (see below).

You can create further ceded participations for a cession group in order to assign several reinsurance
treaties.
2. Creating a participation for an existing cession group manually
You usually create the first participation for a cession group together with the cession group itself. The
system works in the same way when it creates cession groups.
If you want to create an additional participation for a cession group manually (for example, to cover
unplaced risk), go to the cession group and choose in the application toolbar.
3. Assigning a reinsurance treaty manually
For more information about how to assign the liability of a ceded participation to a ceded treaty in Basic
System, see Assigning Master Treaties [page 120].
4.5.6.3 Processing Cession Groups
Functions for Processing Cession Groups
Original business: create cession For more information, see Creating

group for policy sections Cession Groups and Participations
[page 119].
Ceded business: cession group crea Cession Group Creation pushbutton in For more information, see Cession
tion an accumulation group or policy (if not Group Creation [page 93].
assigned to an accumulation group)
Ceded business: create manual ces For more information, see Manual Ces
sion sions [page 128].
Edit cession group For more information, see Initial Screen

for Processing Policies, Groups, and
Participations [page 34].
Default values for cession groups The system enters the default values You can define defaults for the Exten
automatically when you create cession sion Service, value types, and group
groups. This also applies for the groups fields.
created automatically by the cession
You make the settings in external Cus
group creation function.
tomizing for FS-RI Risk Manager (Non-
Life) under RM Functions Edit
Function for Creating Cession Groups .

4.5.6.4 Handling Unplaced Risk
Unplaced risk exists if the liability of the cession group has not been fully distributed to ceded reinsurance
treaties and the retention after automatic cession calculation or manual assignment of reinsurance treaties.
The Liability Overview tab page for the group shows if there is still unplaced risk.
Before you can set a participation to a “Posting Allowed” status (via the superior object), you must allocate all
the assumed liability.
 Note
Exception: If the Carve-Out checkbox has been set the system does not check whether all the assumed
liability has been allocated.
To allocate the unplaced risk, you can either increase the retention, or assign it to a facultative reinsurance
treaty.
● To assume the risk yourself, enter the additional retention in the Additional Retention field on the Liability
Overview tab page. When you save your entry, the system updates the amount in the Not Covered field.
● To cede the unplaced risk to a ceded reinsurance treaty, create an additional ceded participation for the
group, and assign this participation to the treaty. For more information, see Manual Cessions [page 128].
4.5.6.5 Reversal of Cession Groups
Use
You use this function to reverse cession groups and related objects.
Features
Reversal of Cession Group Periods
You cannot set the status within a cession group to "Reversed" manually. However, if you reverse the assumed
side of the cession group (participation), this change is also reflected in the status of the cession group.
For more information, see Creation of Reversal Groups [page 123].
Difference Between Manual and Automatic Reversal
You can select the Manual Reversal checkbox in Customizing for FS-RI Reinsurance under FS-RI Risk
Manager (Non-Life) Policy Administration Edit Statuses . You can select this checkbox only for reversal
statuses. If you select the checkbox when cession groups are created, the system checks this setting when a
reversed cession group period is reopened for processing by the function for creating cession groups.
If the ceded participation was reversed automatically, it is also be reopened for processing by the function for
creating cession groups. If the participation is reversed manually, the status of the participation remains
"Reversed".

4.6 LUD
Definition
LUD is the umbrella term for information on limits, underlyings, and deductibles.
You can define LUDs for each value insured period, policy section period, and participation period, and assign
them to certain reference categories.
Use
On the LUD tab page, you can enter data for each value insured, policy section, or participation, and assign a
reference category. Examples of reference categories include losses, loss events, or certain years. A ranking
sequence is used to weight the entries.
The LUD tab page comprises the following fields:
● Rank
● LUD category
● Use for cession calculation
● Maximum amount
● Currency
● Exchange rate type
● Area
● Peril
● Loss class
● Index type
● Date
If you set the Use for Cession Calculation checkbox, the system uses the value when it calculates the total
liability.
4.7 Structural Characteristics and Splits in Policy Sections

and Participations
Structural Characteristics in Policy Sections
You define and use structural characteristics and splits in Risk Manager policy sections in the same way as in
treaty sections in Basic System [page 277].
However, certain aspects are handled differently for exclusions [page 132].

Structural Characteristics in Participations
The system determines the relevant structural characteristics for the participation on the basis of the
characteristics for the assigned policy section (adjusted for any exclusions for the policy section),
the characteristics for the participations between the policy section and the participation being evaluated, and
the characteristics for the participation itself.
The coverage scope of a ceded participation of a carve-out cession group is the subset of the following:
● The structural characteristics of the logical policy sections or participations minus the exclusions defined
for the assumed and ceded participations
● The structural characteristics of the assigned ceded master treaties minus the exclusions defined for the
treaty
 Note
The treaty details determine the coverage scope of the participation.
4.7.1 Exclusion of Structural Characteristics/Combinations in

a Policy Section or Participation
Definition
In SAP Reinsurance Management for SAP S/4HANA (FS-RI), an exclusion in a policy section or participation
means that a structural characteristic in a covered hierarchy is excluded from the defined coverage or that a
combination of structural characteristics is excluded (the individual characteristics themselves are covered).
Use
You use exclusions to restrict the coverage for a policy section or participation.
For more information about exclusions in Basic System treaties, see Exclusion of Structural Characteristics/
Combinations in a Treaty [page 281].
Options
● Individual areas, classes and lines of business (only the end nodes of a covered hierarchy node, such as
"Europe Without Switzerland")
● Combinations of structural characteristics, for example coverage of fire and water damage in the United
States, Mexico, and Canada, but excluding the combination "Fire in Mexico"
Constraints
● The policy section or participation must not be fully excluded. It must contain at least one combination of
entries from the respective split tables that has not been excluded. Any given split table entry may be
excluded only once in conjunction with the same entries.

● The main characteristics and combinations of split table entries for a policy section or participation must
still be unique after the exclusions have been taken into account.
● You must make sure that at least one combination of all the main structural characteristics is available at
any given point in time.
● You cannot exclude split table entries that contain percentage values.
● You cannot exclude hierarchies if an individual end node within the hierarchy has already been excluded.
Time Limit
You can also restrict the time period for which exclusions apply.
In Risk Manager, the exclusion period must fall within the policy section period or participation period, and
reflects the occurrence period. Depending on your settings, the system enters the above periods as default
values when you create exclusions.
Structure
In Risk Manager, you create exclusions at policy section level or at participation level.
Integration
You cannot split, release, or retrocede accounts and postings that contain excluded characteristics (or an
excluded combination of characteristics).
4.8 Confirmation of In-Force Business
Use
When you confirm a policy or accumulation, it is ready to be posted by accounts. You confirm a policy or
accumulation by converting its status [page 72] to a status with the attribute Posting Allowed.
Features
Confirmation of All Lower-Level Objects
You can confirm only one superior object. The superior object is always the accumulation group or the policy (if
an accumulation group has not been assigned).
When you confirm the superior object, the system sets all the policy sections, groups, and participations under
the superior object to the same status.

Check
If the Check checkbox has been selected for the target status, the system runs checks when it saves the object
in this status. The system settings in Customizing for FS-RI Risk Manager (Non-Life) determine which checks
are performed.
Summarization of Periods
It may be the case, particularly in constellations with accumulations, that some policy sections or
participations are divided into multiple individual periods. Each period split is then propagated into all the
objects belonging to the same superior object. When you confirm an object, these detailed periods are re-
grouped on the ceded business side into larger periods if the liability is the same in the detailed periods.
For more information, see Summarization of Periods [page 134].
Activities
Set the status to a status with the checkbox Posting Allowed and save.
4.8.1 Summarization of Periods
Use
When a new period is created for an existing policy section or participation or when a new period is created by
splitting an existing period, Risk Manager propagates the new periods along the participation chain to the
ceded business side.
Multiple group and participation periods are created for these objects and these can be grouped (or
summarized) into one period if they have the same liability, for example. The summarization of these periods
reduces the volume of data, for accumulations in particular, improves system performance, and increases
transparency.
It may be necessary to summarize periods after the following events:
● An existing policy section or participation period has been split (status change). (Periods are subsequently
split on the ceded business side.)
● A policy section or participation period has been created for an existing policy section or participation
header.
● A policy section period or a participation period has been changed so that there are no differences between
two periods on the ceded business side according to the summarization criteria (for example, the assumed
liability of neighboring periods is aligned).
Periods are summarized when you confirm the object (by setting it to a status that allows posting).

Prerequisites
You have activated summarization in external Customizing for FS-RI Risk Manager (Non-Life) under RM
Functions Condense Periods .
Features
Automatically ceded cession group periods are summarized regardless of whether automatically or manually
ceded participations are assigned or whether automatically ceded participations are changed manually.
If you select this checkbox, the system condenses the following manual groups:
● Manual cession groups

● Prior cession groups
● Manual/automatic cession groups
The system always condenses the data for a group and the assigned participations together.
The following groups are not condensed:
● Reversal groups
● Prior reversal groups
● P2R cession groups
Generally, a group is not condensed if it is assigned a connecting participation.
When a group is condensed, the system copies from the most recently condensed period the criteria values
that are not listed as relevant for grouping together and that can therefore be different.
If the accounting mode is set to “Occurrence Year”, the system uses the start date of the summarized period as
the underwriting date. The system condenses all the periods that meet the following criteria.
Criteria for Group Periods
● The setting for the liability indicator is identical in the group periods.
● The setting for the Carve-Out checkbox is identical in all periods.
● The underwriting date for the group periods is identical (applies only in underwriting year mode).
● The reinsurance program is identical.
● The reinsurance program period is identical.
● The setting for the cession calculation indicator is identical in the periods.
● The total liability (including currency and exchange rate type) and the total liability in percent are identical
in the group periods.
● The retention for cession calculation (including currency and exchange rate type) and the retention for
cession calculation in percent are identical in the group periods.
● The additional retention (including currency and exchange rate type) is identical in the group periods. The
gross liability (including currency and exchange rate type), remaining liability (including currency and
exchange rate type), unplaced risk (including currency and exchange rate type), unplaced risk in percent,
estimated cession to date (including currency and exchange rate type), estimated cession to date in
percent, applied retention (including currency and exchange rate type), and applied retention in percent
are identical in the group periods.

● The Extension Service fields are identical.
 Note
You can override this last criterion with the individual entries in the BAdI /MSG/H_RM_STANDARD_BADI,
method: CONDENSE_ES_GRP. If required, contact your system administrator.
Criteria for Participation Periods
● The underwriting date for the participation periods is identical (applies only in underwriting year mode).
● The reason for changing a status is identical in the participation periods.
● The currency, exchange rate type, rank, treaty section number, loss adjustment expenses, covered
amounts, customer reference, reference rank, coverage reference, control indicator for retention, and
accounting frequency are identical in the participation periods.
● The signed line amount (including currency and exchange rate type), signed line percentage, gross liability
(including currency and exchange rate type), remaining liability (including currency and exchange rate
type), written line percentage, share of liability in coverage reference (including currency and exchange rate
type), share of retention in coverage reference (including currency and exchange rate type), signed NP
share, facultative NP share, written NP share, premium percentage, utilization percentage, calculation base
for the coverage reference (including currency and exchange rate type), and retention amount of the
participation (including currency and exchange rate type) are identical in the participation periods.
● The exclusions (including class of business, business type, line of business, area covered, underwriting
area, peril, validity start and end date) are identical in the participation periods.
● The LUD data (including rank, area number, peril, currency, loss class, exchange rate type, LUD category,
minimum and maximum amount (including currency and exchange rate type), percentage, reference date,
liability index, index type, and cession calculation indicator) are identical in the participation periods.
● The data for the relevant treaty LUDs (including rank, area number, peril, currency, loss class, exchange
rate type, LUD category, minimum and maximum amount (including currency and exchange rate type),
percentage, interlocking checkbox, accounting unit, indexation clause, multiline/multiyear checkbox, and
cession calculation indicator), loss adjustment expenses, covered amounts, and protected share are
identical in manual, non-proportional obligatory participation periods.
● The business partners (including partner function number, business partner role, address, business
partner number, checkbox for standard address, bank details, contract person, and payment method) are
identical in the participation periods.
● The reinstatement schedules (reinstatement number from/to, reinstatement method, percentage,
account date, and degree of usage) are identical in the participation periods.
● The result-independent conditions (including condition category, premium reserve calculation method,
rank, calculation base, percentage, result-independent entry code, accounting time for portfolio rule,
validity start date, validity end date, minimum amount, maximum amount, currency, exchange rate type)
are identical in the participation periods.
● All specified non-statistical value types (including currency, exchange rate type, value, percent/per mille,
number, and the setting that indicates whether the value is fixed) are identical in the participation periods.
● The Extension Service fields are identical.
 Note
You can override this last criterion with the individual entries in the BAdI /MSG/H_RM_STANDARD_BADI,
method CONDENSE_ES_PRT. If required, contact your system administrator.

 Example
A policy section has two policy section journals:
Journal A January 1, 2008 to June 30, 2008 EUR 1,000,000
Journal B July 1, 2008 to December 31, 2008 EUR 1,000,000
You participate 50% in both periods and cede 100% of this to a retrocessionaire.
When you confirm the policy in which this business is mapped, the system recognizes that the ceding
participations contain the same liability (EUR 500,000) and summarizes the two participations into a single
participation period.
4.9 Renewal
Use
During the renewal process you can automatically renew policies up to the ceded business side.
Features
The following functions support the renewal process:
● Renew the assumed business side using the Renew Policy function
● Renew manual cessions on the ceded business side using the Renew Cessions function
4.9.1 Renew Policy
Use
During the renewal process you can automatically renew policies on the assumed business side.
The Renew Policy function is used during the renewal process.
The Renew Policy pushbutton is available in the policy header. When you use this function, the system carries
forward all existing policy sections, values insured, premiums, groups, and participations for the policy to the
new period.

Prerequisites
The objects of a policy that you want to renew must meet the following requirements:
● The previous period has not been reversed.

● There are no gaps between the previous period and the new period.
● The renewal period is not in the past.
● The corresponding treaties are valid in the new period. This applies to your own participation.
Features
The system renews one policy per policy section including the corresponding objects. These are:
● Values insured
● Premiums
● Policy section groups
● Cedent participations
● Cedent participation groups
● Own participations
● Accumulation assignments
The system creates a new period to which it copies all the period-dependent data of the most recent period,
provided the prerequisites are met.
 Example
There are two periods in 2012: January 1, 2012 to September 30, 2012 and October 1, 2012 to December 31,
2012. If a policy is renewed for 2013, the system copies the data from October 1, 2012 to December 31,
2012 to the new period.
The following data is not copied because it is not period-dependent:
● Result-dependent conditions
● Premium schedule
● Distribution plan
If there is an assignment to an accumulation, this is also renewed. The system adjusts the validity of the
accumulation to match the renewal period provided this period does not already exist in the accumulation.
If the policy has underwriting year policy sections, the period for which the policy is assigned to the
accumulation and the new validity of the accumulation are based on the underwriting date.
 Example
An accumulation is valid from January 1, 2012 to January 1, 2013. A policy is assigned to this accumulation.
The accounting mode of the policy section is set to “Occurrence Year”. The policy section has the following
period: October 1, 2012 to October 1, 2013. The renewal of the policy for October 1, 2013 takes places by
October 1, 2014. The system extends the assignment of the policy to the accumulation and the
accumulation period to October 1, 2014 (inclusive).
An accumulation is valid from January 1, 2012 to January 1, 2013. A policy is assigned to this accumulation.
The accounting mode of the policy section is set to “Underwriting Year”. The policy section has the

following period: October 1, 2012 to December 31, 9999. The underwriting date is October 1, 2012. The
renewal of the policy for October 1, 2013 takes place by December 31, 9999 for the underwriting date
October 1, 2013. The system extends the assignment of the policy to the accumulation and the
accumulation period to 10/1/2013 (inclusive).
When you have performed a renewal, only the new periods are assigned the selected processing status. The
existing periods are not affected. In other words, if these periods had a status that allowed posting then they
still have this status and you can still post data to the participation periods.
Activities
When you choose the Renew Policy pushbutton in the policy header, a dialog box appears in which you can
enter the following:
● Renewal period (required entry)

● Underwriting date (required entry if the accounting mode of the policy section is “Underwriting Year”)
● Status
● Customer reference (the customer reference of the participation)
The renewal period is determined based on the policy section journal.
 Example
Example for a policy section with the accounting mode “Occurrence Year”: The policy section journal has
the period October 1, 2012 to September 30, 2013. A renewal period from October 1, 2013 to September
30, 2014 is suggested.
Example for a policy section with the accounting mode “Underwriting Year”: The policy section journal has
the period January 1, 2013 to December 31, 9999 and the underwriting date January 1, 2013. A renewal
period from January 1, 2014 to December 31, 9999 and the underwriting date January 1, 2014 are
suggested.
The default values for status and reason for change are determined in Customizing for FS-RI Risk Manager
(Non-Life) under Policy Administration Edit Statuses .
Expected Result
All the policy sections and related values insured, premiums, groups, and participations that meet the
conditions for renewal are carried forward.
4.9.2 Renew Cessions
Use
During the renewal process you can automatically renew manual cessions on the ceded business side as well
as prior cessions.

The Renew Cessions function is used during the renewal process
and the Renew Cessions pushbutton is available in the liability overview of the cession group. When you use this
function, the system carries forward all existing manual cessions from the previous period to the new cession
period.
Prerequisites
Before you can use the Renew Cessions function, you must have already renewed the assumed business side.
In the case of ceded business, this data is delivered for the most part via the interfaces.
The cession being renewed must meet the following criteria:
● The previous period has not been reversed.

● There are no gaps between the previous period and the new period.
● The corresponding treaty is valid in the new period.
Features
For each cession being renewed, the system copies all the period-dependent data of the most recent previous
period.
 Example
A renewal is being run for 2012 and there are two periods in 2011 (from January 1, 2011 to September 30,
2011 and from October 1, 2011 to December 31, 2011). The system copies the data of the period from
October 1, 2011 to December 31, 2011 to the new period.
The following data is copied:
● Participation value types

● Exclusions
● Limits and deductibles (LUDs)
● Result-independent conditions
● Reinstatement
● Business partner of participation
● Extension Service of participation period
The accounting mode is taken into consideration during a renewal:
● If the cession being renewed and the cession group have the same mode (“Occurrence Year” or
“Underwriting Year”), the period is copied from the cession group.
● If the cession being renewed has the mode “Underwriting Year” and the cession group has the mode
“Occurrence Year”, the period from the cession group is created in the cession being renewed as the new
underwriting year with underwriting date.

 Example
The cession group is renewed in the period from January 1, 2012 to December 31, 2012. The system
creates the underwriting year from January 1, 2012 for the cession with the underwriting date January
1, 2012.
● If the cession being renewed has the mode “Occurrence Year” and the cession group has the mode
“Underwriting Year”, automatic renewal is not run. The system informs you that you have to perform the
renewal manually in this case.
Activities
We recommend the following procedure:
● Renewal of prior cessions

Before you renew prior cessions, you must create the new period for the prior cession group. You can then
carry forward the prior cessions by choosing the Renew Cessions pushbutton.
● Automatic renewal using cession group creation/cession calculation
Once the assumed business side has been renewed, you can run the renewal for the mandatory cessions
by executing the Cession Group Creation/Cession Calculation function.
● Renewal of facultative cessions
The Renew Cessions pushbutton is available in the cession group. When you use this function, the system
carries forward all existing facultative cessions from the previous period to the new period.
Expected Result
The manual cessions that meet the criteria for renewal have been carried forward.
4.9.3 Overall Renewal
Use
During the renewal process you can run an overall renewal. This is supported by a number of automatic
functions.
Activities
We recommend the following procedure:
● Renew the assumed business side using the Renew Policy function
● Generate the obligatory cessions using the Cession Group Creation and Cession Calculation functions
● Renew manual cessions on the ceded business side using the Renew Cessions function
Expected Result

The policy, all its dependent objects, all assumed groups and participations, and all related ceded obligatory
and manual cessions have been renewed.
4.10 Risk Manager Accounting Process
Use
You use the functions covered by this process to enter and calculate postings for premiums, losses,
commission and other items, and to generate open items in the current account system.
Prerequisites
● The participation chain for which you are creating postings has a status with the attribute “Posting
Allowed”.
● Basic System treaties for which you are creating postings have a status with the attribute “Posting
Allowed”.
● Your current account system (FS-CD) is connected and has been configured correctly.
Process
The steps for processing a Risk Manager account have a fixed sequence. This section looks at the individual
processing steps in order.
Entering Posting Data
The first step is to enter the posting data in an account. You can either do this using Bordereau Manager, which
enables you to process a set of postings and distribute them to new accounts, or create an individual account,
which is processed using the standard posting screen.
You can group postings in an account only if they all relate to the same participation. When you create an
account, you must specify the participation header. This cannot be changed retroactively.
If you are changing existing data, you can only change the business type and currency if the new values match
all the postings.
You can still change the involvement, FI posting date, and accounting period. You can also add postings to the
account, or delete existing postings.
For more information, see Creating Risk Manager Accounts [page 150].
Distributing Reinsurer Shares
Once you have entered all the data for the account, you can distribute the account to all the partners involved in
the treaty, assuming no involvement has been entered in the account itself.

A separate account is created for each share (involvement), and the postings are assigned the relevant
amounts for the share in question. After it has been split, the original account can no longer be changed.
However, you can still process the partial accounts.
When you split accounts, you can apply filter conditions (such as "Stop", "Filter" and "Transfer").
An account does not need to be split if it has already been entered or generated for a share (involvement). This
can be the case for assumed business, for example. Retrocession accounts that have been generated
automatically are usually created without a share and therefore have to be split later on.
For more information, see Splitting Risk Manager Accounts [page 152].
Calculating Accounts for Shares
You can calculate derived values for accounts in which the shares have been specified. This function applies the
result-independent conditions defined for a participation or at “Risk Manager” level in the treaty to the relevant
postings in the account. This enables you to calculate commission payments automatically on the basis of the
premium payments, for example.
The search for the valid conditions is based on the revenue period of a posting and the determined treaty
period. If conditions are found for the policy section (in other words, in the policy section period relating to the
revenue period), these override conditions with the same rank or target entry code that have been defined for
the treaty period.
For more information, see Calculating Risk Manager Accounts [page 155].
Transferring the Account
Once account processing is complete, you can transfer the account data. There are two options: You can
transfer the account to Basic System, or transfer it to the retrocession side. You can only transfer accounts to
the retrocession side if the account belongs to an assumed treaty and as such to assumed participations, or if
it has been created in a reinsurance company code by a connecting treaty (Accounts should always be
transferred to the relevant areas until they have the status “Transferred”).
Once an account has been transferred, it can no longer be changed.
Transfer to Reinsurance/Retrocession
When you transfer an account to the retrocession side, the system creates accounts for the ceded
participations that are assigned to the assumed participations via the cession groups. These ceding accounts
are assigned the status "Pending" and can be processed further in Risk Manager. They may or may not have a
share. The system sets the appropriate status, enabling you to perform the next logical processing step in a
background job.
When you transfer accounts, you can apply filter conditions (such as "Stop", "Filter" and "Transfer").
For more information, see Transfer to Reinsurance/Retrocession [page 159].
Transfer to Basic System
This function creates accounts in Basic System for the individual treaty sections when postings in the Risk
Manager account reference these sections. (The system determines the sections when you save, and stores
them invisibly in the postings.) In a similar way to the Release function in Basic System, the system creates
opening reserves at Risk Manager level.
The accounts created in Basic System are assigned the status “Pending” and retain the share specified in the
Risk Manager account. These accounts can be processed further in Basic System, which primarily involves
applying the Basic System conditions to the account using the Calculate function, and then transferring the

account data to the current account system (FS-CD) using the Release function. When you release the Basic
System accounts, corresponding open items are created in the current account system. See also:
● Transfer to Basic System [page 163]

● Accounting Process [page 347] (for Basic System)
Example
For an example of the process, see Example: Accounts [page 191].
4.10.1 Mergers and Acquisitions
You can use transfer groups to process portfolio transfers individually.
For more information about transfer groups and how to use them, see the documentation [page 307] for
mergers and acquisitions in Basic System.
For more information, see Mergers and Acquisitions:Procedure [page 315].
4.10.2 Transfer Exchange Rate
Use
The legal requirements of different accounting principles stipulate that when premium postings are processed
further (for example, unearned premiums are calculated) the exchange rates used are copied to the derived
account.
To fulfill this requirement, you can define for specific accounting functions in certain company codes the
postings for which you want to transfer the translation date.
Features
You can transfer the translation date for currency translations from the source accounts to the target accounts
for the following accounting processes:
Accounting Process Scope

Reserves carried forward The translation date of the underlying opening reserves is
transferred to the corresponding closing reserves, and vice
versa. This applies for the following functions in Basic Sys
tem and Risk Manager:
● The generation of opening and closing reserves using

the following background jobs in Schedule Manger
(transaction SCMA), task list /MSG/FSRI0:
○ Carry Reserves Forward to Target Year (Basic
System) (/MSG/R_A_BATCH_CARRY_FORWARD)
○ Carry Reserves Forward to Target Year (Parallel)
(Basic System) (/MSG/
R_ABR_CARRY_FORWARD_PP)
○ Carry Reserves Forward for Key Date (Basic
System) (/MSG/R_A_BATCH_CFWD_KEYDATE)
○ Carry Reserves Forward for Key Date (Parallel)
(Basic Syst.) (/MSG/
R_A_BATCH_CFWD_KEYDATE_PP)
○ Carry Reserves Forward to Target Year (Risk
Manager) (/MSG/H_FI_P_BATCH_OP_CL_RES)
○ Carry Reserves Forward for Key Date (Risk
Manager) (/MSG/
H_FI_P_BATCH_OP_CL_RES_KD)
● The generation of opening reserves when an account is

released
Release of accounts for participating treaty and connecting The translation date is transferred from the source accounts
treaties to the target accounts only if a rule to this effect has been
defined in Customizing for the target company code. If it has
not, the system re-determines the translation date in the tar
get account.
Retrocession The translation date is transferred from the inward account

to the outward account. This applies for the following func
tions:
● Retrocession (Basic System)

● Retrocession (Risk Manager)
● Treaty calculation rule
● Retrocession adjustment (Basic System)
● Retrocession adjustment (Risk Manager Non-Life)

Unearned premium The translation date is transferred from the premium to the
unearned premium using the following background jobs:
● Calculate Unearned Premiums (Risk Manager) (/MSG/

H_FI_P_BATCH_CARRYFWD)
● Calculate Unearned Premiums (Basic System) (/MSG/

R_A_BATCH_BUE)
Activities
To transfer the translation date, you must define the entry codes in which this rule applies for each accounting
process for which you want to use this function.
 Caution
Note that you can enter only premium entry codes that have been marked as reserves.
 Note
You can also declare a reinstatement entry code as a loss entry code. In this case, you cannot enter a
reinstatement entry code.
You can define entry codes for specific company codes or for all company codes.
 Tip
We recommend that you perform this transfer while the system is running only if all affected premium
postings have been earned in full. Otherwise, subsequent calculations may product incorrect results.
Revaluation of Reserves
When it revalues reserves, the system filters out and ignores entry codes for which settings have been made in
Customizing to transfer the translation date when unearned premiums are calculated and reserves are carried
forward (Basic System or Risk Manager).
You can make the Customizing setting under FS-RI Reinsurance Basic System Accounting Accounting
Principles Settings for Transfer of Exchange Rate .
Release of Accounts for Participating Treaty and Connecting Treaty
When you release accounts for a participating treaty and for connecting treaties, the translation date can be
transferred from the source accounts to the target accounts only if a rule to this effect has been defined in
Customizing for the target company code. You can make the Customizing setting under FS-RI Reinsurance
Basic System Accounting Accounting Principles Settings for Transfer of Exchange Rate by setting the
checkbox Rel. All ("Release Across Company Codes").
Retrocession

You can specify in the target treaty for the retrocession or the treaty calculation rule whether you want to
transfer the translation date from the source account or whether you want to redetermine this date as follows:
1. On the SAP Easy Access screen, call transaction /MSG/R_V2 under Insurance Reinsurance Basic
System Treaty Non-Life .
2. Select a treaty that has the treaty category “Retrocession”.
3. On the Section Header tab page, select a section.
4. Branch to the Section tab page at section level by double-clicking the section.
5. On the Section tab page under Structure Elements, make the corresponding settings in the Currency
Handling During Retro Transfer field.
6. Choose Save.
Unearned Premium
We recommend that you make the following settings in Customizing under FS-RI Reinsurance Basic
System Accounting Accounting Principles Settings for Transfer of Exchange Rate :
● To transfer the exchange rate correctly in Risk Manager when unearned premiums are calculated in a
flexible way, we recommend that you use a combination of the following two checkboxes to ensure that the
translation date produces the correct results:
○ UEP RM ("Flexible Methods for Unearned Premiums (Risk Manager")
○ CFWD BS ("Category of Carryforward (Basic System)")
● To transfer the exchange rate correctly in Basic System when unearned premiums are calculated using
patterns or at the end of a period, we recommend that you use a combination of the following checkboxes
to ensure that the translation date produces the correct results:
○ UEP BS ("Flexible Methods for Unearned Premiums (Basic System)")
○ CFWD RM ("Category of Carryforward (Risk Manager)")
○ Rel. All ("Release Across Company Codes")
To ensure that the correct translation date is forwarded to the current account module, you must make the
corresponding settings on the relevant interface.
4.10.3 Risk Manager Account
Definition
The business object “Account” is a collection of postings for a participation. These are either postings that
occur over a certain time period or postings that occur as the result of a certain event.
 Note
The FS-RI object “Risk Manager Account” should not be confused with the “Account” in Basic System or
the year-end or quarterly statement that you send to your reinsurer or retrocessionaire. This statement can
contain data from several account objects.

Use
You use the account as a “shell” for postings. You cannot make a posting without an account and for this reason
the FS-RI system always uses accounts when a posting is to be made. You can create accounts manually, or
have them generated by the system. Each account must contain at least one posting.
Accounting Functions
In addition to the standard actions Create, Edit, and Delete, you can perform the following actions for an RM
account:
● Split (the system splits the posting data for an account according to treaty involvement)
● Calculate (the system calculates result-dependent conditions and creates condition postings)
● Transfer the account to Basic System
● Transfer an inward account (assumed business) to the ceded business side (reinsurance/retrocession)
● Reverse (create offsetting postings for accounts that have been transferred or split)
For more information about accounting functions, see the relevant subsections in this documentation.
Account Status
Accounts can have different statuses, such as “Pending”, “Split”, and “Transferred”. The system resets the
status when it performs an accounting function. If you perform a function manually, the account is assigned
the status determined by the system. If you perform a function using a background job, you can define an
alternative target status before starting the background job for the generated or processed accounts. The
system processes the accounts up to the specified target status.
Structure
An account comprises header data and posting data (on the tab pages). The header data defines the
participation and treaty for which the account applies, as well as the relevant time frame and currencies. The
posting data contains the posting amounts, occurrence and underwriting years, areas, and so on, for each
posting in the account.
You can change certain account header data. However, you cannot change the account number, which is
assigned as a fixed key. Likewise, you can no longer change the participation and the assigned treaty. Changes
to the status are restricted, and are only possible for the status "Pending". The status is used to flag the
account for the next relevant background job.
Postings
The characteristics a posting can have are similar to those in Basic System [page 349]. You must also specify a
revenue period that must be covered by the participation. This period is used to determine the underwriting
year and occurrence year (which may only be determined after the posting has been split). If you assign an
underwriting year, you must enter the underwriting date manually.
The structure of the postings you enter must match the structure of the participation and the structure of one
of the sections of the treaty specified in the header data of the account. The original currency may also be
treated as a structural characteristic that has to be validated. This depends on whether a corresponding
setting has been made in external Customizing for Basic System under Default Values Edit Defaults for
Accounting .

Integration
Accounts can be generated by background jobs. For more information, see the documentation for the
background jobs.
4.10.3.1 Reserve Postings in Risk Manager
Use
Reserve postings are postings that are generated to create or release reserves (for losses, for example) or
carryforwards (for premiums, for example). A reserve posting has an entry code for which you have set the
Reserves checkbox in Customizing for Basic System under Accounting Entry Code Edit Entry Code
Definitions .
Prerequisites
You have created a specific entry code for the reserves in Customizing for Basic System under Accounting
Entry Code Edit Entry Code Definitions .
Features
Entry of Reserve Postings
You can enter reserves wherever you can enter other postings:
● On the Postings tab page in an individual account

● In a bordereau
● In a loss
You can also enter reserves on the following screens in the account, which offer additional functions:
● On the Reserve Balance tab page in the account: On this tab page, you can view and change the current
balance of the reserves for the participation for each entry code and period. To create this status, the
system adds together all the reserve postings for this account and all the reserve postings from earlier
accounts that have already been transferred to Basic System.
● If you change the data, the system creates a posting for the amount required to reach the new reserve
balance, or it creates a clearing and a new posting. You can change the data here only if the account has
the status “Pending”.
When you save the account or loss, the system updates the data on the other tab pages with the changes
made.
Clearing, Posting, or Delta

You can either change the reserve amounts by posting a change amount (delta) or by clearing the entire
amount and reposting the target amount. You can do this in Customizing for Basic System under Defaults
Values Edit Defaults for Accounting (Calculation Fields) .
Effectiveness of Reserve Postings
Reserve postings can be relevant for financial accounting or purely statistical. This is defined by the entry code
used for the posting. You define this in Customizing for Basic System under Accounting Entry Code Edit
Entry Code Definitions .
● If the entry code is relevant for financial accounting, the financial year must match that of the account.
● If the entry code is statistical, the accounting year must match that of the account.
● If entry codes are statistical and relevant for financial accounting, the financial and accounting year must
match those of the account.
This enables the system to determine the total for the postings so that it can calculate the reserve.
Reversal of Accounts
When you reverse an account, you can deactivate the reversal of reserve postings according to company code
and the actual/estimate indicator. You make these settings in Customizing for Basic System under Default
Values Edit Defaults for the Reversal Function .
Reserve Carryforwards
You use the background jobs Create Closing Reserves and Carry Reserves Forward to Target Year (Risk Manager)
to carryforward reserves when switching from one period to another.
 Note
For more information, see Mergers and Acquisitions:Procedure [page 315].
4.10.3.2 Creating Risk Manager Accounts
Procedure
1. Enter the participation and choose Enter. The system enters the header data based on the participation. In
accounts created manually for ceded participations, you can also enter the assumed participation number.
In doing so, you can enter only assumed participations that are linked with the ceded participation. The
system then identifies and saves the assumed cedent.
2. Check the header data, and make any necessary changes. You can also add further data, such as the
currency, accounting year, and accounting period.
3. Enter the postings you want to create. The posting must all correspond to the treaty, but can relate to
different treaty sections.
4. Save the account. When you save the account, the system performs the following actions:

○ It runs validation checks for the postings and fills the dependent fields. If there is a critical error during
the checks, the system does not save the account. Instead, it displays an error message. When you
save the account, the system assigns an account number and changes the operating mode.
○ It checks whether the revenue period for a posting covers more than one validity period for the
participation or treaty, or more than one financial year. If this is the case, it creates corresponding
subpostings. Splitting the postings is essential for further processing (transferring accounts,
calculating conditions, and so on). When postings are split, the revenue period of the original posting is
divided up and the posting amount is allocated to the subperiods on a pro rata temporis basis. The
duration of the time periods depends on the days per year rule in Customizing and the time rule for the
policy section to which the posting relates. With the "360 days" rule, each month is taken to have 30
days. The "365 days" rule reflects the real number of days, but does not take leap years into account.
In the "366 days" rule, the full 29 days are counted for February in a leap year. The time rule
determines whether or not the last day in a period is included. Subpostings are displayed in blue
directly under the original posting. They are sorted in ascending order according to the revenue period
and cannot be changed manually. If you change the original postings, any existing subpostings are
adjusted automatically. However, this is only done when you next save the account. There are some
exceptions relating to the creation of subpostings: If a posting is made for a non-pro rata temporis
participation, the posting is never split. If you select the option Only Generate Subpostings on the Basis
of Accounting Modes in Customizing, the system only splits the postings where this is necessary to
determine the correct treaty period. You can also make a Customizing setting to split the revenue
period at the start of a new financial year.
Results
You can also enter new postings or change existing postings for accounts that have been saved, but not yet
transferred. If the account has already been split or transferred, you must use the reversal functions to make
any changes.
4.10.3.3 Copying Risk Manager Accounts
Context
You use this procedure to use data from an existing account as the basis for creating a new account.
Procedure
1. Open the account you want to copy and choose .

2. The system creates a new account with the same data and postings and with the status “Pending”. You can
then edit this account as required. When you copy an account, the system creates a reference between the

source and target account. This is intended only as additional information for the user and does not affect
further processing.
4.10.3.4 Splitting Risk Manager Accounts
Use
If an account references a Basic System treaty, but does not reference a Basic System participation
(involvement), it can be split according to the signed line percentages defined in Basic System (for reinsurers
and the unplaced risk). To do this, the system creates new accounts with the status “To Transfer to Basic
System”. If a Basic System participation has already been created or generated for the account, you do not
need to execute the Split function.
Prerequisites
● The account has already been checked for consistency.

● The treaty to which the postings relate and all the treaty periods upon which the signed line percentages
are based have a status that allows posting.
Features
Basic System Data for Splitting the Account
The signed line percentages relevant for the split are stored under the Basic System treaty period on the
Participations tab page. For accounting purposes, only the Basic System shares with the categories “Signed
Line” (for a reinsurance involvement) or “Not Placed” (no involvement) apply.
In the case of assumed treaties, postings are only made for reinsurance involvements if the reinsurer has a
company code in the system.
Additional conditions apply for selecting the Basic System participations according to which Risk Manager
postings are distributed:
● The Basic System participation must belong to the treaty period that contains the treaty section
determined by the system for the Risk Manager posting.
● If an additional validity period has been defined for the Basic System participation, the percentage defined
for the participation is only applied if the start of the accounting period for the account is within this period.
● The Basic System participation may be restricted to a certain treaty section. In this case, the system
checks this treaty section against the treaty section determined for the Risk Manager posting. If a Basic
System participation applies only to a given treaty section, it takes priority over unrestricted Basic System
participations under the same treaty period. This prevents double calculations.
Filtering Target Postings

After the original postings have been split, the system filters the target postings. As with the Calculate function,
the system uses result-independent conditions. There are three categories:
● “Stop” (postings are not transferred)

● “Filter” (postings are transferred on a percentage basis)
● “Transfer” (postings are posted to a different entry code)
The system first processes all the conditions from the master treaty and the relevant Risk Manager
participation in their ranking order. For each generated posting, it checks if the criteria of the current condition
are fulfilled. It also checks if the entry code is defined in the calculation base for the condition or is the same as
the target entry code (except for “Transfer Posting”). In this case – depending on the condition category – the
system either deletes the posting entirely, or multiplies it with the condition percentage and assigns a new
target entry code. Following the filter process, the new accounts are created on the basis of the most recent
posting data.
Connecting Treaties
If the accounts reference a connecting treaty, the system initially creates only the outward accounts for the
reinsurer participations. The symmetrical inward Risk Manager accounts are created later when the outward
accounts are transferred to Basic System.
References to Risk Manager Participations
References to the Risk Manager participations (original participation, preceding participation, participation
relevant for posting) are retained when accounts are split and transferred to the target accounts. The account
split is an interim step (before the transfer to Basic System) based on the structure of the master treaty in
Basic System. It ensures the that the accounts can be processed in Basic System and in the current account
system.
Unplaced Participations
If the split function selects a participation with the category “Not Placed” (this would be the case for pseudo
assumed treaties), the system first searches for the cedent involvement on the basis of the cedent relevant for
the account. The target account is then created for this cedent involvement. In this special case, the cedent of
the account is also entered as reinsurer and business partner; if the cedent company does not have its own
company code, the system creates the target account in the company code of the Risk Manager participation.
Activities
Calling the Function
There are various options for calling the function manually or automatically:
Manually:
● Within an account using the Split or Split, Calculate pushbuttons (if you choose Split, Calculate, the system
runs the Calculate [page 359] function directly after splitting the accounts)
● From the selection screen for the accounting transaction
● From a bordereau (after generating accounts)
● From the loss transaction

Automatically:
● Using the background job for splitting accounts. The job processes the treaties specified for the run and
only selects accounts with the status “To Be Split”. This ensures that pending accounts are not processed
by accident.
● As part of the background job for signed line adjustments for Risk Manager accounts. In this case, the
system repeats the split process for accounts that have already been split and stores the differences to the
existing subpostings as adjustment accounts.
Process Flow
1. The system reads the effective percentage rates for the split from Basic System.
2. It determines the valid percentages for each posting on the basis of the treaty period, the start of the
accounting period and (where applicable) the treaty section. It then applies these percentages to create
target postings.
3. If an account is distributed 100%, the system adjusts for rounding differences.
4. The system checks for filter conditions and executes them.
5. The system generates accounts for the target postings.
6. The system sets the status of the original account to “Split”. After it has been split, the original account
can no longer be changed.
7. The system creates account references that allow you to navigate between the original and target accounts
and any adjustments made later on.
Example
Example 1: Ceded Obligatory Treaty
A ceded obligatory treaty has the following participation profile:
Involvements
● INV1: Cedent COMP1

● INV2: Reinsurer COMP2
Basic System participations
● INV2: 20%
● INV3: 30%
● INV4: 50%
Assume you split a ceded 100% account that was created by the Transfer to Re/Retro function in the company
code of cedent COMP1. In this case, 20% of each posting amount is posted to involvement INV2 of company
COMP2, 30% to involvement INV3, and 50% to involvement INV4.
Example 2: Pseudo Assumed Treaty
A pseudo assumed treaty has the following participation profile:
Involvements
● INV1: Cedent COMP1 with the company code of the treaty

● INV2: Co-cedent COMP2 with its own company code
● INV3: Co-cedent COMP3 with its own company code
● Not placed: 100%
If you split a 100% account of the cedent COMP2, the full 100% is posted to involvement INV2 in the company
code of COMP2. If the 100% account had a different cedent, the target account would be created for a different
involvement in a different company code.
Example 3: Participations with Specific Validity Periods
An obligatory ceded reinsurance treaty with several treaty sections has the following participation profile for
the treaty period 2004:
Involvements
● INV1: Cedent COMP1 with the company code of the treaty

● INV2: 50%
● INV3: 30% (January 1, 2004 – December 31, 2004) and 20% (from January 1, 2005)
● INV3: 15% (January 1, 2004 – December 31, 2005) and 10% (from January 1, 2006)
Assume you want to split an account for the accounting year 2005, whereby all the postings relate to treaty
sections 3 and 4 for the treaty period 2004. 50% is posted to involvement INV2. 20% is posted to INV3 for
treaty section 3, and 15% to INV4 for section 4.
4.10.3.5 Calculating Risk Manager Accounts
Use
You use the “Calculate” function if the Risk Manager participation or treaty for which you are creating accounts
contains conditions.
It determines which activities need to be carried out for result-dependent conditions in the participation for
which postings are being created, and calculates and creates the corresponding postings.
Examples of result-independent conditions include commissions, insurance taxes, transfer postings, and
posting filters.
 Note
Risk Manager Non-Life does not support technical accounting functions for result-dependent conditions,
since there is no formal basis for establishing revenue development.

Prerequisites
● The accounts have not yet been transferred to Basic System, which means that you can perform
calculations for individual accounts.
● The accounts to be calculated must reference involvements in Basic System.
Features
The system determines which of the conditions defined in the Risk Manager participation or assigned master
treaty need to be calculated based on defined criteria (see Criteria for the Validity of a Condition [page 157]).
For each condition to be calculated, the system analyzes the postings to see which postings qualify. Using this
posting dataset, it then calculates the total for the calculation base and calculates the expected posting. The
expected posting is compared to the corresponding existing postings and adjusted accordingly before the
posting is made. This means you can use this function to adjust conditions that have already been calculated
when the underlying posting data has changed.
Activities
You can call the accounting function in the following ways:
● You can call the function manually from within the participation you are processing, using the Calculate or
Split, Calculate pushbuttons. Alternatively, choose Account Calculate in the menu or choose F6 .
● You can call the function manually from the selection screen for the accounting transaction or manually
from a bordereau (after generating accounts).
● You can call the function manually from a loss.
● You can use the adjustment background job, which calculates and adjusts all the conditions for the
specified treaties across all accounts. In this case, the posting data is summarized and not processed
separately for each account.
● You can use various background jobs that incorporate this function.
● You can confirm a participation chain. When you do so, the system checks if accounting is active for the
participations in this chain, and whether conditions exist for these participations that are linked to a
change in the target status after confirmation. If this is the case, the system executes this function.
Calculating the Condition
1. The system reads all the result-independent conditions for the relevant posting period from the
corresponding master treaty and participation. For more information, see Criteria for the Validity of a
Condition [page 157].
2. The system analyzes when conditions from the master treaty in Basic System are overridden by conditions
from the participation. For more information, see Criteria for the Validity of a Condition [page 157].
3. The conditions are applied successively, based on their ranking.
4. The system selects and summarizes the relevant postings based on the applicable periods (treaty period
or validity period and underwriting date of the participation, validity period of the condition).

5. It checks the entry codes of the postings against those defined in the calculation base of the condition, and
summarizes the amounts of the matching postings. This is the assessment basis for calculating the
condition amount. The plus/minus sign of each partial amount depends on the Customizing settings for
the respective entry code and the calculation base.
6. The system multiplies the assessment base amount by the defined percentages or calculated pro rata
rates and assigns a target entry code (“expected”). The amounts are not posted directly at this stage.
Instead, they are first compared with postings that have a matching structure (“actual”).
7. The actual posting the system makes depends on the Customizing settings, and is either the calculated
difference, or the “actual” amount as a negative entry (reversal) and the “expected” amount as a positive
entry.
8. Once all the conditions have been processed, the new adjustment postings are added to the respective
original account or to a new account with the status “To Transfer to Basic System”.
Example
A condition has been defined to post 20% of the gross premium as commission under entry code 2100.
The following postings have already been made: premiums of EUR 10,000 and EUR 5,000 (under entry code
1701, which is specified in the calculation base for the condition)
, a commission advance of EUR 2,000 (under entry code 2100), and a loss payment of EUR 12,000 (under
entry code 3100). These postings qualify for the condition according to the criteria described below.
To calculate the amount for the condition, the system first selects all the above postings. The resulting
assessment base (calculation base) is EUR 15,000 for the two postings with the entry code 1701. The amounts
for entry codes 2100 and 3100 are not added. The system generates an expected posting of EUR 3,000 with
the entry code 2100. This is then compared to the actual posting of EUR 2,000 from the selected posting data.
Depending on the Customizing setting, the system either posts EUR -2,000 (reversal of actual amount) and
EUR 3,000 (expected value), or just EUR 1,000 (difference between actual and expected values).
4.10.3.5.1 Criteria for the Validity of a Condition
A condition is applied to a given posting if the time frame and structure of the posting matches that of the
condition. If there are several similar matching postings, the system uses override logic to select the relevant
entry.
Validity Period
The posting must fall within the validity period of the condition, which is determined by the treaty period or
participation period and the validity period for the condition itself. The following prerequisites apply.
Prerequisites for Applying a Risk Manager Condition

A Risk Manager condition is applied to a Risk Manager posting under the following circumstances (without
considering the override logic and condition validity periods):
● The revenue period of the posting falls within the participation period for which the condition is defined. If
the participation does not allow pro rata temporis distribution, the first day of the revenue period must be
within the participation period.
● If the condition has been defined for a participation period with “Underwriting Year” mode, the
underwriting date of the posting must match the underwriting date of the participation period.
Prerequisites for Applying a Basic System Condition
A Basic System condition with the calculation level “Risk Manager” is applied to a Risk Manager posting under
the following circumstances (without considering the override logic and condition validity periods):
● The treaty period for treaty section determined by the system matches the treaty period defined for the
condition.
● The treaty section determined by the system matches the section defined for the condition. This
prerequisite is also fulfilled if no treaty section has been defined for the condition.
● The accounting unit for the posting matches the accounting unit for the condition. This prerequisite is also
fulfilled if no accounting unit has been defined for the condition.
● The involvement in the account header matches the involvement for the condition. This prerequisite is also
fulfilled if no involvement has been defined for the condition.
Validity Period of the Condition Itself
The validity period for a condition can also be restricted by condition-specific validity periods (in addition to the
validity periods for the assigned entities in Risk Manager and in Basic System).
In terms of the accounting period, a condition applies to a Risk Manager posting if the start of the accounting
period in the account header falls within the validity period of the condition. If no validity period has been
defined for a condition, it is valid indefinitely.
 Example
Two commission rates are defined for a participation period from January 1, 2003 to December 31, 2003:
15%
(2003) and 5% (2004). 15% commission is calculated for the normal premium posting for 2003. If
premiums for the revenue period of January 1, 2003 to December 31, 2003 are adjusted retrospectively in
2004, the lower commission rate applies. Such terms might be agreed by the partners involved.
Override Logic
If several similar conditions (at different abstraction levels) match the structure and validity period of a posting,
the override logic determines which condition applies. If a commission rate of 10% has been specified in the
Risk Manager participation, for example, but a rate of 15% for the relevant treaty section, only the posting for
the Risk Manager participation applies. The override logic allows you to create standard conditions for the
treaty in Basic System (general conditions), and override them by creating conditions for individual
participations (specific conditions). The override logic also ensures consistency by preventing multiple
calculations for conditions.

The following rule applies: A posting no longer qualifies for a condition (with a given rank and target entry
code) if it qualifies for a specific condition with the same rank or with the same target entry code. The hierarchy
begins with “general” conditions (1), and moves towards “specific” conditions (3) as follows:
1. Conditions defined for the treaty in Basic System that are not restricted by involvement, accounting unit,
or treaty section
2. Conditions defined for the treaty in Basic System, which are restricted by involvement, accounting unit, or
treaty section. In this case, the involvement takes priority, followed by the accounting unit, and then the
section
3. Conditions defined for the participation in Risk Manager
For more information about the override logic in Basic System, see “Global Condition”.
 Example
In the master treaty in Basic System, 10% commission and 12% insurance tax has been defined for the
treaty period 2004. A commission rate of 12% has been defined for section 3 of the treaty for the same
period. The commission rate in a related Risk Manager participation is 15%. If a posting qualifies for all the
conditions in terms of the validity period, the posting would only be considered for calculating the
insurance tax and the 15% commission. The insurance tax is not overridden by a more specific setting.
However, the general commission rate of 10% and the section-dependent commission of 12% is overridden
by the rate for the Risk Manager participation. If the Risk Manager condition did not qualify, the section
commission of 12% would be calculated for the posting.
Related Information
Global Condition [page 251]
4.10.3.6 Transfer to Reinsurance/Retrocession
Use
You use the Transfer to Re/Retro function to distribute the postings in an account to the next participation level.
Based on the reinsurance structure, the system posts the shares for the various participations according to the
rules defined for cession calculation and liability aggregation.
Integration
If you make changes to the in-force business, the system adjusts the accounts created by this function
automatically.
For more information, see Retrocession Adjustment [page 172].

Prerequisites
● The account to be transferred has been validated.

● The relevant Risk Manager objects are open for posting.
Features
Transferred Postings
The function transfers posting data entered for an assumed participation. It can therefore be applied to
accounts relating to an assumed treaty or to duplicate accounts for a connecting treaty.
 Note
Original policies and their policy sections, and participations with the category “Retention” cannot be
posted.
Since you can map the entire reinsurance structure in the system with a chain of successive participations, you
can distribute a posting across the entire chain from the first known reinsurer to the last known
retrocessionaire by repeating this function (together with the functions Split and Transfer to Basic System).
Target Postings
The system creates postings for participations. These participations may be assigned to a ceded treaty or
connecting treaty. Depending on the assigned treaty, the system proceeds as follows:
● Participations with a ceded master treaty in Basic System: The system creates only ceded postings.
● Participations with a connecting treaty: Postings can be created for connecting treaties in the same way as
for normal ceded treaties. If you enter a (ceded) 100% account in the system (an account without a Basic
System participation), and execute the Split [page 152] function, the system first creates outward
accounts for the reinsurers. These accounts remain in the cedent's company code. If you transfer these
accounts to Basic System, they are also copied within Risk Manager and stored as inward accounts in the
company codes of the reinsurers, if such company codes exist. All accounts refer to the same Risk
Manager participation and to the same master treaty in Basic System.
Activities
Calling the Function, Variants
● Call the function manually from an inward account on the assumed business side.
● Run the Transfer Accounts to Retrocession background job.
● Call the function during retrocession adjustments after making changes to the in-force business.
Process Flow
1. Determine target participations: The system determines the ceded participations assigned to the
assumed participations that relate to the postings: It uses cession groups and prior cession groups
assigned to the assumed participations to find the ceded participations and process these in ascending

order by rank and reference rank and to find the cession values defined therein (cession percentage, NP
structures, premium percentage, and so on). These values are then stored temporarily. In the case of a
carve-out, the system also checks the posting data being transferred against the exclusions and partially
covered treaties of the ceded participations.
2. Filter the posting data: The system analyzes the accounts transferred and filters out the posting data not
to be transferred [page 162].
3. Prior cessions: The system determines whether prior cessions have to be taken into account. If this is the
case, it applies the prior cession values to the inward postings and generates the outward postings and
accounts. If the prior cessions exist in the new format, the cession values are applied to the posting share
according to the calculation base. It also considers filter conditions, LUDs, and signed line percentages
defined for the ceded participations. Loss and premium postings are calculated in the same way as
cessions. The inward postings are reduced by the corresponding values.
4. Cessions: The system applies cession values determined for the cession groups to the reduced inward
accounts and generates outward accounts. If the cessions exist in the new format, the cession values are
applied to the posting share according to the calculation base. It also considers filter conditions, LUDs, and
signed line percentages defined for the ceded participations. Loss and premium postings are calculated as
follows.
Posting Category Ceded Participation Type Amount Posted
Premium Proportional Posting share according to calculation

base x (premium percentage or
signed line percentage)
Premium Non-proportional Posting share according to calculation

base x premium percentage
Loss without loss number Proportional Posting share according to calculation

base x signed line percentage
Loss with loss number Proportional Posting share according to calculation

base x share of liability in coverage ref
erence
Loss with loss number Non-proportional Liability according to LUD data
5. Create accounts: For each ceded participation (that is, for each treaty in Basic System; an account is not
created for participation with the category “Retention”), the system creates a new Risk Manager account
containing the postings it covers. You can process these accounts further using the available accounting
functions.
6. Set account status: The system sets the status of the inward account to “Transferred”. The status of
outward account is set to "To Be Split". These accounts have not yet been assigned to an involvement in
the master treaty and have to be split before they can be processed further.
 Example
Example with a Connecting Treaty
Reinsurer RE1 assumes a risk through an assumed participation OS1 ("our share", from the viewpoint
of RE1). This participation is assigned to the reinsurance participation RP1, via the group G1. RP1 is
assigned to a connecting treaty with Basic System participations RE1 (cedent, ceded) and RE2

(reinsurer, assumed). This means that RE2 assumes the business from RE1. The participation RP1 is
now passed on to a ceded participation RP2 via the group G2. RP2 may be linked to another reinsurer,
such as RE3.
With this new concept, it is possible to enter an account for the share OS1 in the company code for RE1
and then to transfer it to RP1 (first "Transfer to Re/Retrocession"). When the generated accounts are
split across the master treaty shares and transferred to Basic System, an inward Risk Manager account
is created in the company code for RE2. This can then be transferred to RP2 (second "Transfer to Re/
Retrocession").
You can therefore map the reinsurance chain across a whole group and create accounts across several
company codes.
4.10.3.6.1 Posting Data Not Transferred
The following posting data must not be transferred to the reinsurance/retrocession side, and is therefore
filtered out by the system:
● Opening reserves and reserves carried forward

Reserves are carried forward for each individual participation. If these carryforward postings were
transferred from the assumed business side, the postings would be made twice on the ceded business
side.
● Revenue periods not to be transferred
When you run the retrocession adjustment job, the system transfers only additional postings that fall within
certain periods. If a corresponding parameter in the accounting function is filled, the system excludes all
the postings that fall outside the specified time periods. The postings that partly fall within the specified
periods are split according to the “pro rata temporis” method to include only the relevant portion of the
posting.
● Filter BAdI (original)
You can implement your own filters for the posting data on the assumed business side. You can also
change the posting data, in addition to defining filters.
● Entry codes without retrocession
Postings with entry codes for which the Retrocession checkbox has not been set are ignored by the Transfer
to Re/Retro run.
● Lack of coverage in the case of a carve-out
Postings that cannot be processed because the Carve-Out checkbox has been set for a ceded participation
due to lack of coverage are ignored by the Transfer to Re/Retro run.
4.10.3.6.2 Transfer to Non-Proportional Retrocession Treaties
When accounts are transferred to the retrocession side, the loss amounts in the account are offset against the
respective liability amounts (if liabilities have been defined).
These can be defined in the ceded non-proportional treaty (see Limit, Underlying, Deductible (LUD) [page
272]) or in the ceded participation. Otherwise, the expected results are comparable with those of the non-
proportional account [page 369] in the loss module.

Premium postings are transferred provided you have entered a premium percentage in the ceded participation
(see Participation Premium [page 109]).
4.10.3.7 Transfer to Basic System
Use
You can use this function to use the postings created for a participation in Risk Manager to generate
corresponding postings for the treaty sections and treaty periods for the assigned master treaty.
Risk Manager postings can be transferred to the accounts receivable/payable only via Basic System. This
function can also release the postings in Basic System automatically.
Prerequisites
● An involvement must be entered in the source account.

● The account must be consistent. The system checks for consistency before the transfer, and also runs
validation checks from Basic System.
● The Account Transfer from RM checkbox must be selected for the relevant treaty. This checkbox is on the
Header Data tab page in the Control Data section.
● Posting must be allowed for the affected treaty periods and Risk Manager objects.
● The system must find suitable treaty periods and treaty sections in the treaty designated for posting. For
more information, see Determination of Sections and Periods [page 165].
Features
The function covers the following activities:
● Determination of the treaty sections and periods relevant for the postings
● Consistency and validation checks for the posting data
● Generation of postings and accounts in Basic System
● Closure of the accounts in Risk Manager
● Optional: release of postings in Basic System to the current account system (accounts payable/receivable)
● Optional: creation of opening reserves
Connecting Treaties
If the account to be transferred references a connecting treaty (or, more precisely, an involvement flagged for a
connecting treaty), a symmetrical inward account must be created in Risk Manager if the participating partner
has its own company code in the system. The inward account is assigned this company code automatically.
Preceding Functions
Reserves

Opening reserves are posted for closing reserves (if the corresponding settings have been made in
Customizing for Basic System under Default Values Edit Defaults for Accounting ).
For more information, see Carry Reserves Forward to Target Year (Risk Manager) [page 548].
Fill Table WKLISTEC
The data from the transferred account, including the postings, is written to the statistics table /MSG/
HWKLISTEC. The system also determines other dependent information and duplicates it in this table to support
simpler and faster evaluations later on.
Itemization
If you have set the checkbox for itemization in the Risk Manager participations, the system retains the
participation references for the posting. The posting amounts are not summarized across participations.
Activities
The function can be called as follows:
● Online for an account you are currently processing

● From the selection screen for the accounting transaction
● From a bordereau (after generating accounts)
● From the loss transaction
● Using a background job. The background job also offers a summarization option. If you activate
summarization, the system does not process the accounts to be transferred individually, but first
summarizes the postings for all accounts. The job does not select all the matching accounts, but only
those with the status “To Transfer to Basic System”. This ensures that pending accounts are not
transferred by accident.
Process Flow
1. The system conducts various validation checks to ensure that the posting matches the data and settings in
Basic System and in the current account system. This includes coverage checks for loss and deposit
postings, as well as checks for the Premium Payment Warranty function.
2. Reserves (see above)
3. WKLISTEC (see above)
4. During the transfer to Basic System the system assigns the postings from the transferred accounts to the
sections of the assigned treaty. It then creates an account for each treaty section affected.
5. The Risk Manager accounts are assigned the status “To Transfer to Re/Retro” or “Transferred” (final
status). This depends on whether a transfer to the retrocession side is possible.
6. For navigation purposes the system creates references between the source and target accounts.
7. If you have made the corresponding setting, the accounts generated in Basic System are released
automatically. This closes the postings permanently and transfers them to the current account system
(where appropriate). The user must have the necessary authorization to release accounts (see the
documentation about the Basic System account). If the automatic release setting is not active, the
accounts generated in Basic System are assigned the status “Pending”. You can then release the accounts
separately, and change them first if necessary. (Once an account has been transferred, no more changes
should normally be made.)

 Note
If the account to be transferred references a treaty that excludes transfers to Basic System, the system
skips all the transfer steps. In this case, it changes only the account status to a final status. Otherwise, the
account would permanently have the status “Pending” or “To Transfer to Basic System”.
4.10.3.7.1 Determination of Sections and Periods
Use
To transfer a Risk Manager account to Basic System successfully, the system must find a matching treaty
section and period for each posting (or subposting, if the postings have been split). Both the treaty and the
period are required to apply the posting to the master treaty in Basic System.
Features
The system looks for the relevant sections and periods within the specified treaty that match the posting. The
treaty is determined by the cession calculation function, or entered manually. Since the treaty period can
depend on the accounting mode of the treaty section, and the structural characteristics of a section can vary
between periods, the system searches for both entities simultaneously.
Section
A section qualifies if it covers the structural characteristics of the account (business type, currency), the
posting (class/line of business, underwriting area, accounting unit) and - where applicable - of the referenced
loss (peril, coverage area). Any split table entries and exclusions defined for the treaty section are taken into
account. You can opt whether to incorporate the currency check.
Period
The relevant period depends on the section and the type of posting (premium entry code or loss entry code).
For each section and type of posting, you can set the accounting mode as follows:
● Occurrence year:
The system selects the treaty period that includes the occurrence date of the posting. The occurrence date
is equivalent to the start of the revenue period for the posting or subposting.
● Underwriting year:
The system selects the treaty period that includes the underwriting date of the posting. (In the case of
participations with the mode “Underwriting Year”, you must always enter the date. When participations
have the mode “Occurrence Year”, the system can determine the date automatically, since the validity
periods do not overlap.)
● Accounting year:
The system selects the treaty period that includes the start of the accounting period for the account.

4.10.3.8 Direct Release of an Account from Risk Manager
Use
You can release accounts from Risk Manager without having to go to the current account system via Basic
System.
The system transfers these accounts to Basic System in the same step. However, the accounts are not
available in the current account system.
The system releases an account by transferring a Risk Manager account to Basic System online and using a
background job. In doing so, it considers the derivation rules and exclusions entered in Customizing.
The system does not generate a document in the current account system for Basic System accounts that are
generated when an account is released directly. These accounts have the status “Released”. You can process
these accounts further in retrocession and using treaty calculation rules.
 Note
The system no longer executes the Calculate function for Basic System accounts. This is aimed at
preventing inconsistencies in the statuses of Risk Manager and Basic System accounts and the documents
in the connected current account system.
Integration
The system executes the function by transferring a Risk Manager account to Basic System online and using a
background job.
 Note
● Derivation rules have already been applied in Risk Manager. Derivation rules are no longer applied in
Basic System.
● Result-independent conditions are calculated in Risk Manager.
● Accounts that are created by the direct release of an account cannot be copied to Basic System and
cannot be reversed.
 Tip
In Basic System you can calculate the result-independent conditions using the Adjust Periods background
job.
Prerequisites
You control the direct release of an account using a checkbox. To activate this function you have to select the
Single Transfer to CA System checkbox for individual participations in the master treaty and the Itemization CA
checkbox in the participation.

4.10.3.9 Reversal of Risk Manager Accounts
Use
The purpose of reversing accounts is to reverse the postings belonging to this account and to delete any
postings that have been prepared, but not yet processed.
Features
The system reverses postings that have already been split or already transferred to Basic System by generating
a posting for the same amount, but with the opposite plus/minus sign.
During the reversal run, the system determines the correct financial period and accounting period again. The
new data then applies to the account that contains the offsetting entries (and for any partial accounts that
belong to it).
Opening and closing reserves from other financial years or accounting years are not reversed.
The postings that reverse an account are grouped in a new reversal account. This reversal account is assigned
the status “To Be Split” or, if no split is necessary, “To Transfer to Basic System”.
To reverse a "Pending" account or an account that has not been processed further, you simply delete it. In this
case, the system does not post any offsetting entries or recalculate any values.
Accounts That Have Been Split
If subpostings exist as a result of pro rata temporis distribution, the system creates an offsetting original
posting in the reversal account for each subposting.
Assignment
The system assigns the original accounts to the corresponding reversal accounts, enabling you to trace the
reversal transaction later on.
Activities
The reversal function can be called in the following ways:
● Manually from within an account

● Manually on the selection screen for the accounting transaction
● Manually from a bordereau (after generating accounts)
● Manually from within a loss
● By the system as a subfunction of other functions, such as reversal of premium schedules
Process Flow

1. The system determines whether the accounts to be reversed have already been split or transferred to
Basic System. If this is not the case, it deletes the corresponding accounts, thereby completing the reversal
activity for these accounts.
2. If the accounts have already been split or transferred to Basic System, the system creates a reversal
account with corresponding reversal postings.
3. The system sets the Reversal checkbox in the original account and in the generated offsetting postings.
4. The system creates a reference between the reversal account and the reversed account.
4.10.3.10 Assignments Between Risk Manager Accounts
You can use the assignment table to track the relationships between accounts chronologically. The display is
not just restricted to the accounts directly preceding and following the account in question.
You also see the reason why each account has been assigned (accounting function).
The overview is useful for navigating between accounts.
4.10.3.11 Calculation of the Due Date for a Posting
Use
The due date is the date by which a posting must be paid.
A due date is assigned to every cash posting and to every fund posting in the system.
In the current account system, you can use the due date to control certain functions, such as dunning, or to
trigger payment.
Features
The system calculates and assigns the due date for every posting, whether entered manually or automatically.
You can use the following methods to calculate the due date of a posting.
Automatic Determination of the Rules for Calculating the Due Date
The system has several methods of automatically calculating the due date of a posting. The method that is
used depends on the settings in Customizing. You define the rules for these methods in Customizing for Basic
System under Accounting Configure Method of Calculating Due Date .
For more information about these methods, see:
● Methods for Automatic Calculation of Due Dates in Basic System [page 352]
● Methods for Automatic Calculation of Due Dates in Risk Manager [page 169]
Treaty-Specific Rules for Calculating the Due Date

If you want to apply different rules from those defined in Customizing to a certain treaty, you can use Due Date
Manager [page 336] to define your own rules for calculating the due date in the treaty.
Rules entered in Due Date Manager have a higher priority to rules entered in Customizing.
Manual Creation or Changing of the Due Date
If you want to define a different due date for a posting from that calculated by the rules in Customizing or by
Due Date Manager, you can manually overwrite this date in the posting provided the account has a status that
can be changed.
If the system cannot calculate a due date, it does not fill the field provided and you must enter the date
manually to be able to release the account.
4.10.3.11.1 Methods for Automatic Calculation of Due Dates

in Risk Manager
The system uses the methods described here to calculate the due dates for postings.
1. Calculation based on the time limits entered in the Risk Manager participation and in the treaty
The system calculates the due date for the posting as follows (see below for a table of the italicized dates
and an example):
1. The system identifies the accounting periods of the treaty. The duration of the individual accounting
periods is indicated by the accounting frequency. The position of the accounting periods is determined
by the first accounting key date, which specifies the last day of the first accounting period. Subsequent
accounting key dates occur at the intervals specified in the accounting frequency.
2. The system calculates the due date for account processing. It does this by finding the accounting key
date of the accounting period that contains the date on which the account was received and adding the
account creation period to this date.
3. The system calculates the due date for the posting. It does this by adding the settlement period from
the participation and the account review period from the treaty to the due date for account processing.
(The latter applies only if the treaty contains an involvement.) If the treaty contains an involvement and
you have not entered the settlement period in the participation, the system adds to the due date the
settlement period after account receipt or after account confirmation from the treaty.
Calculation of Due Dates According to Time Limits Using Example Values
Data Field Tab Page Example Value Calculation
Treaty period Treaty: Treaty Period January 1, 2007 – Decem Manual entry
ber 31, 2007
Accounting frequency Treaty: Header Data QUART (3-monthly) Manual entry
First accounting key date Treaty: Header Data April 10 Manual entry
Account creation period Treaty: Header Data 15 days Manual entry

Settlement period after ac Treaty: Partners Involved 20 days Manual entry
count receipt
Settlement period after ac Treaty: Partners Involved (none) -

count confirmation
Account review period Treaty: Partners Involved 10 days Manual entry
Settlement period RM Participation 20 days Manual entry
Date received Account: Account June 5, 2007 Manual entry
Accounting period Internal period (for details April 11, 2007 – July 10, ○ First accounting key
of calculating this period, 2007 date = April 10 (see
see step 1) above), accounting pe

riods after April 10 oc
cur at three-monthly
intervals
○ Date received (June 5,
2007 - see above) lies
in the period April 11,
2007 – July 10, 2007
Accounting key date Internal date (for details of July 10, 2007 = end date of accounting
calculating this date, see period (see above)
step 1)
Due date for account proc Account: Account (for de July 25, 2007 = July 10, 2007 (end date of
essing tails of calculating this date, accounting period) + 15
see step 2) days (account creation pe
riod)
Due date for posting Account: Posting August 24, 2007 = July 25, 2007 (due date
for account processing)
+ 20 days (settlement pe
riod) + 10 days (account re
view period)
2. Copy the due date from the premium schedule

In the case of generated postings, the system copies the due date from the premium schedule in the
participation.
When the system copies generated postings to the retrocession side and it cannot find any suitable entry
for the entry code used, the “Due Date” field is left empty.
In the case of manual postings, the system does not fill the “Due Date” field.
3. Setting the field to “Not Due”
The system sets the due date to December 31, 9999.
4. Entering the current date
The system uses the current date when it creates the posting.
5. Using the due date of the original account

The system uses the due date of the original account. This may be relevant for accounting functions such
as Split or Transfer to Basic System.
 Note
In the case of treaty calculation rules, sometimes the system cannot find an original account if you do
not select the “Individual Accounts” checkbox in Customizing for Basic System under Default Values
Edit Defaults for Accounting (Calculation Fields) .
6. No default values
The system does not fill the “Due Date” field; you must enter this date manually.
7. User-defined methods
If you require additional methods to those delivered in the system, you can develop these as individual
enhancements and make them available in Customizing under Maintain Accounting Settings Edit
Method of Calculating Due Date . For more information, contact your SAP consultant.
4.10.4 Accounts for Connecting Participations
Use
When you create accounts for a connecting participation, the system considers the assumed and ceded
business mapped in the connecting participation.
Prerequisites
Corresponding connecting treaties for the connecting participation exist in Basic System.
Features
When the outward Risk Manager account is transferred to Basic System, the system simultaneously creates an
inward Risk Manager account in the company code assuming the business.
You can also define in Customizing for FS-RI Reinsurance under Basic System Default Values Edit
Defaults for Accounting (using the Transfer to Original Amount and Currency (Transfer) checkbox) whether
when you release an outward account belonging to a connecting participation the system transfers the
following data to the “Original Amount” and “Original Currency” fields in the inward account:
● The original amount and currency

● The amount posted and currency
If you want to transfer the account currency as the original currency and the currency check has been
activated in the system (Transfer to Original Amount and Currency (Transfer) and “Currency Check”
checkboxes have been set), when you release the accounts in Risk Manager Non-Life the system checks

whether the Risk Manager Non-Life policy covers the currency and whether the corresponding master treaty
contains the account currency as the original currency in the currency split.
In the event of an error, the system cancels the release of the account and displays the corresponding error
message.
4.10.5 Retrocession Adjustment
Use
You can use this function to check whether accounts have been retroceded correctly and to create any
necessary adjustment postings.
It is necessary to adjust a retrocession if changes are made that are relevant to a retrocession. Such changes
can include a change in cession percentage rates or a change of loss area.
Features
When you set a policy or an accumulation group to a status that allows posting using the Confirm pushbutton,
the system automatically checks whether it is necessary to adjust a retrocession and, if it is, performs this
adjustment.
You can adjust the retrocession manually in the following cases:
● After changes to a loss using the background job Adjust Retrocession After Changing Loss (Risk Manager)
(/MSG/H_FI_P_BT_RECALC_LOSS_I2O)
● After changes to a non-proportional retrocession treaty using the background job Adjust Retro After
Changing Ceded Treaty (Risk Manager) (/MSG/H_FI_P_BTC_RECALC_VTG_I2O)
The system checks whether a retrocession needs to be adjusted when you confirm a participation chain by
setting the superior object to a status with the attribute “Posting Allowed”. The adjustment applies only to
participations with postings made on a pro rata temporis basis.
It may be necessary to adjust existing transfer to retrocession because the cession has changed, or because
the assignment of the assumed participation to the cession group or prior cession group has changed.
Possible reasons for adjusting a retrocession as well as the scope of the adjustment are listed below.
Reason Scope of Adjustment
Reversal of assumed participations with calculation of re The system clears the postings for the reversed assumed
turns participation that were generated by retrocession.

Reversal of cessions (ceded participations) The system clears all postings for the reversed participation
periods, including those that were not generated by the
Transfer to Re/Retrocession function (such as expected pre
miums).
Creation of cessions The system transfers the inward accounts to the new ces
sion.
Change in the values in existing cessions that are relevant to In the “Delta Posting” mode:
a retrocession
● The system determines and posts the difference be
tween existing retrocession postings and required retro
cession postings.
In the “Clearing/Posting” mode:
● The system clears the existing retrocession postings in

the changed cession.
● The system transfers the inward accounts to the ces
sion again.
Change in the assignment of assumed participations to ces ● In cessions that are no longer assigned to the assumed
sion groups participation: The system clears the postings that were
retroceded by the assumed participation.
● In new cessions assigned to the assumed participation:
The system transfers the inward accounts to the new
cessions.
Reversal with calculation of returns/reversal without calcula If an assumed participation period is edited and its status is
tion of returns, posting not allowed set to "Active", this triggers the adjustment of the retroces
sion.
Reversal without calculation of returns, posting allowed The system also adjusts the retrocession for the corre
sponding participation period, but only if postings exist for
the reversal group, or if the percentage rates between the
cession group and reversal group have changed.
The retrocession is not adjusted if only the time periods of the cession group or participation have been shifted
or refined, but the cession percentages, assignments and LUDs for all the time periods are still the same.
Mode in Which Postings Are Created
In Customizing for FS-RI Risk Manager (Non-Life) under Default Values Edit Defaults for Accounting , you
can use the Post Diffs checkbox to specify the mode in which you want to create the postings during when a
retrocession is adjusted:
● Difference posting: The system offsets the amounts that have already been posted against the new
calculated amounts and creates postings for the difference.
● Clearing/Posting: The system clears the amounts that have already been posted and posts the new
amount that is calculated.

4.10.6 Flexible Summarization of Accounts
Use
When accounts are processed by background functions in SAP Reinsurance Management for SAP S/4HANA
(FS-RI) they are first transferred in small summarized forms only. This results in a very high number of
accounts and postings with a very high level of detail.
To reduce the number of accounts, you can define flexible summarization rules for the accounts created by
background jobs.
Features
To summarize accounts, for each background job for which you want to use flexible summarization you must
define the fields in which data is to be summarized. The system then groups the target postings for the
background job in an account even if there is a different entry in one of these fields.
Supported Background Jobs
The option of flexible summarization is available in the following background jobs:
● Process Retrocession Accounts (accounting function: 4)

● Adjust Retrocession Accounts (accounting function: RCORR)
● Process Treaty Calculation Rules (accounting function: TCR)
● Create Opening Reserves in Risk Manager and Execute Reserve Carryforward (Opening and Closing
Reserves) in Basic System (accounting function: OPRSV)
● Transfer Accounts to Retrocession (accounting function: I2OB)
● Transfer Accounts to Basic System in Risk Manager (accounting function: R2BB)
● Execute Transfer (accounting function: TXGRP)
A maximum number of fields across which accounts can be summarized have been defined for each of these
functions.
Special Features
Occurrence and Underwriting Date
The sample Customizing settings contain function modules for recalculating the occurrence and underwriting
date. You must define and implement any additional function modules in the customer project.
“Payment From” and “Payment To”
Accounts are still summarized in Basic System based on the Payment From and Payment To fields. For this
reason, the use of these fields in a bundle, and subsequently in a variant, always applies only to the Risk
Manager functions.
Transfer Group
When accounts are transferred as part of mergers and acquisitions [page 307] they are summarized according
to the selection period.

If the selection period is Year to Date and Inception to Date, flexible summarization is used in the treaty
calculation rule.
If the selection period is Incremental, the account is not summarized.
The Individual Accounts and Summarization checkboxes in Customizing for Basic System under Default
Values Edit Defaults for Accounting , which are applied in the treaty calculation rule during summarization,
are not used by the background job for a transfer.
You can specify whether an account is summarized when a transfer group is used by entering a field bundle in
the header data of the transfer group.
Activities
You define the summarization rules for a background job as follows:
1. Group the required fields in field bundles. You need these bundles so that when you define summarization
variants at a later date you can refer to an identical number of fields. You find the Customizing settings for
the bundles under Basic System Accounting Summarization Edit Bundles .
2. Define the summarization variants in Customizing for Basic System under Accounting Summarization
Edit Summarization Variants . Field bundles are linked with accounting functions in the summarization
variants. You also indicate here whether the generation of account assignments is deactivated for the
accounting functions. You can select this checkbox only for accounting functions for which you are
permitted to deactivate the generation of account assignments. A variant can be assigned multiple
bundles or accounting functions and therefore constitutes a package of summarization rules. You can also
restrict the validity of the assigned bundles or accounting functions to individual company codes.
 Note
In the case of the Execute Transfer background job, the field bundle is stored in the corresponding transfer
group. You do not need to define a summarization variant or enter it in the target treaty in this case.
Entry of Default Values
When accounts are summarized, it is possible not only that certain attributes are not transferred but also that
their contents are set to a default value that is suitable for the target treaty. You can define function modules for
this purpose.
Treaty Calculation Rules
If the Individual Accounts checkbox has been selected in Customizing, the system summarizes the account if a
summarization variant that is not the same as the standard summarization variant has been entered in the
target treaty for the treaty calculation rule.
If the standard summarization variant has been entered and the Individual Accounts checkbox has been
selected, the account is not summarized.
Inactive Summarization Variants
If a summarization variant has been set to inactive in Customizing, you can no longer assign it to a treaty. This
variant continues to apply to the treaties in which it has been entered.

4.10.7 Summary of Accounts
You can use this function to run evaluations on existing accounts and postings.
The system reads the accounts and postings that match your selection criteria from the database and groups
them by account, entry code, and loss. In Risk Manager, you can select according to certain revenue periods or
participations.
In each row, you see the effect on the technical and liquid balance, as well as the technical result.
If you enter a revenue period as one of the selection criteria in Risk Manager, the selection is restricted to the
postings that overlap with this period, and the proportionate posting amounts are calculated on a pro rata
temporis basis. In other words, you see the proportional result for the specified period.
4.10.8 Currency Handling
Determining the Account Currency
The system determines the account currency as follows:
● If an account currency is specified in the data for the business partner share, this currency is used for the
account if currency handling for the share is set to “Share Currency”. This applies if the maximum treaty
year for the share is before or the same as the accounting year.
● If an account currency has been defined for the original currency in the currency split table for the section,
this currency is used as the account currency if currency handling for the share is set to “Account
Currency”. This applies if the maximum treaty year for the section is before or the same as the accounting
year.
● Otherwise, the original currency is used as the account currency.
● The system can determine the account currency for Risk Manager accounts only after you have created a
posting and specified an involvement. Initially, the system assumes the account currency is the original
currency, until the actual account currency can be determined.
Currency Conversion
The following rules apply for translating currencies:
● If the original currency differs from the account currency, the system translates the amount in original
currency into the account currency using the current exchange rate.
● The current rate depends on the translation date (valuation date). You define the valuation date in
Customizing.
● If no Customizing setting has been made for the translation date, the system uses the account creation
date.
● In Basic System accounts that come from Risk Manager, the valuation date is left blank. This indicates that
Risk Manager accounts are never translated into a different currency after they have been transferred to
Basic System.

Currency Validation Check
The system checks if the specified original currency is covered for the entire revenue period for the posting. In
other words, it checks if the original currency is defined in currency split table for the treaty section or
participation related to the posting. You activate the currency validation check in Customizing for Basic System
under Default Values Edit Defaults for Accounting .
4.11 Process-Oriented Example
Definition
This section and the following sections illustrate the basic business process in Risk Manager, from the
incoming side for assumed business to the outgoing side for ceded business.
Note that this is only one possible procedure. In practice, the actual steps will depend on your own
requirements.
The steps marked as “optional” have been included only to complete the picture and are not vital for the
example itself. While the example aims only to introduce the functions, the optional steps go into more detail.
Concept
Structure of the Example
Basic Data
The example looks at two original policies, each with one policy section. These are assigned to one
accumulation group.
Automatic Calculation of Values for Ceded Business
The example assumes you want to create data for the ceded business automatically using the Risk Manager
functions for creating cession groups and calculating the cessions.
Classification of Assumed Risk Using a Class Model
The class model with its related classes serves to classify an assumed risk in Risk Manager. The class defines
the quality of the risk. The quality can be made dependent on various factors, such as the construction type
class or PML. You can define your own criteria using the Extension Service.
Distribution of Risk Using the Reinsurance Program
You can then define the cessions for each class in the reinsurance program. In addition, you need to define a
structure that differentiates the quality of the risk. This is done by assigning certain values for the criteria (such
as PML > 1 million) to a certain risk class. Risk Manager can determine the quality of the risk automatically and
create the ceded participations according to the cession defined in the reinsurance program. To set up this
automatic process, you need to enter information about how the default values for the criteria (such as PML or
construction type class) should be determined, which are in turn used to establish the risk quality.

4.11.1 Example: Creating Assumed Treaties in Basic System
Use
The assumed treaty maps the structure of the assumed business transaction and describes the relationship
between two business partners.
It is also used during processing as an interface to financial accounting when the accounts are settled. The
treaty contains information about the treaty type, treaty category, business type, treaty direction, period, area,
currency, and class of business.
This treaty is used as the master treaty in the header for assumed participations. The structure and period of
the participation must fall within the scope of the master treaty. The master treaty must cover all the risks
covered by the assigned participations.
In the case of a carve-out, the treaty must cover at least one combination of class of business, area, business
type, line of business, peril, and currency of the assumed participation. These do not have to be the main
structural characteristics.
Structure
Key Data
Treaty Period Classes of Area Business Type Line of Busi Currency

Business ness
EING_VERTRAG January 1, 2006 Fire World 10 EUR

- December 31,
2006
Procedure
(Explanations are provided in parentheses after the entries)
1. Choose FS-RI: Reinsurance Basic System Treaty Create Treaty .

2. Enter:
○ Treaty category: 1 (for assumed reinsurance)
○ Company code: (any, select a suitable company code)
○ Nature of treaty: P_FAC (for proportional-facultative)
3. Choose New. The Create Prop. Treaty <INTERNAL>: Header Data screen appears.
4. Enter:
○ Treaty name: (any)
○ Cedent: (any)

○ Treaty effective from: January 1, 2006
○ Account level: original
○ Set the Use in RM and Acct Transf. from RM checkboxes.
○ Enter the relevant responsibilities. You select these using the input help.
5. Switch to the Periods tab page and select the row for the specified period. The Create Prop. Treaty
<INTERNAL>: Sections screen appears.
6. Create a section. The header data for the section appears.
7. Enter:
○ Section number
○ Section name
Confirm your entries.
8. Enter:
○ Class of business: fire
○ Area: world
○ Business type: 10
○ Currency: (any)
○ Exchange rate type: (any)
○ Accounting mode: occurrence year
10. Switch back to the Periods tab page by returning to the level above.
11. Set the status of the period to a status with the attribute “Posting Allowed” (the Canceled checkbox must
not be selected).
4.11.2 Example: Defining and Processing Class Models

(Optional)
Use
For general information about class models and the procedure for defining them, see the corresponding
section in Class Model with Risk Classes [page 61] and Risk Classes for Cession Calculation [page 99].
Structure
The class model in this example is intended to differentiate between fire insurance coverage for buildings with a
sprinkler system and for those without. To do this, you define the following data:
● Name of the class model: FIRE

● 1. Class: A (with sprinkler system)
● 2. Class: B (without sprinkler system)

4.11.3 Example: Creating Ceded Master Treaties
Use
This example looks at defining the ceded obligatory master treaties. These are the treaties to which you
distribute the Risk Manager exposures via the reinsurance program.
The treaties must cover at least the period and structure of the portfolio treaty sections assigned to the
reinsurance program. The maximum cession of individual treaties must also be specified.
Structure
The example uses the following treaties: ceded quota share treaty
Ceded Quota Share Treaty

Business ness
AUSG_VTG_QU January 1, 2006 Fire World 10 EUR

- December 31,
9999
Surplus Treaty

Business ness
AUSG_VTG_SU January 1, 2006 Fire World 10 EUR

- December 31,
9999
Procedure
Create the first treaty, and then the second. To create the treaties, proceed as follows:
1. Choose FS-RI: Reinsurance Basic System Treaty Create .

2. Enter the required data:
○ Treaty: name of the treaty (for example, ausg_vtgsu(qu))
○ Treaty category: 4 (for ceded reinsurance)
○ Nature of treaty: PROBL (for proportional obligatory – you need to make this entry here in order to opt
for a quota share or surplus treaty later on in the example).
3. Confirm your entries by choosing . The Change Prop. Treaty ausg_vtgsu(qu): Header Data screen
appears.

○ Treaty name: AUSG_VTG_QU and AUSG_VTG_SU
○ Treaty effective from: January 1, 2006
○ Account level: original
On this screen you must also set the “Use in RM” and “Acct Transf. from RM” checkboxes (otherwise, the
treaty cannot be used in Risk Manager and for Risk Manager accounts).
Enter the corresponding responsibilities and save your entries.
5. Switch to the Periods tab page and enter the end date December 31, 9999.
6. Double-click the row for the period you have entered.
(The sections (classes of business, areas, and so on) must be assigned directly to the period.)
7. Choose Create.
Specify whether you want to create a quota share treaty or a surplus treaty. The Create Prop. Treaty
ausg_vtgqu(su): Sections screen appears.
○ Section number: 1
○ Section name: fire
Confirm your entries and enter values for the following fields (these fields are ready for input upon
confirmation):
○ Treaty type: Choose a corresponding treaty type
○ Class of business: for example, "Fire" (any additional classes of business must then be added on the
“Classes of Business” tab page after the other required entries have been made)
○ Area: for example, "World"
○ Business type: for example, "10"
○ Currency and exchange rate type: EUR, M
If you are creating a surplus treaty, you also have to enter a layer (such as 1). This determines the rank of
the treaty in relation to other treaties with the same underlying treaty type.
Choose the Quota (or Surplus) tab page, and enter the quota percentage or the maximum liability (retained
line and number of lines).
Quota Share Treaty
○ Quota share percentage: 100
○ Maximum liability: 10,000,000
Choose “Enter” to confirm.
Surplus Treaty
○ Retained line: 1,000,000
○ Number of retained lines: 10
9. Enter a reinsurance share for each treaty.
To do this, switch to the Partners Involved tab page and enter an involvement with the role category RI
(reinsurer) and a participating company. Save your entries.
Return to the level above and switch to the Participations tab page. Enter the number of the involvement
you have just created. For this example, enter 100 in the Share in % field.
10. Complete the treaty creation process.
Save your treaties and set the status of the treaties in the journal to a status with the attribute Posting
Allowed (the Canceled checkbox must not be selected). Save your entries.

4.11.4 Example: Creating Reinsurance Programs
Definition
Create a reinsurance program using the following data. For more information, see Reinsurance Program [page
690].
Concept
Structure of Reinsurance Program
1. Enter the individual values:

○ Name of Reinsurance Program: Reinsurance program
○ Partner: your owner company
○ Module: Risk Manager
○ Class Model: If you have defined the optional class model in these examples (FIRE), enter this class
model here. If you have not defined this class model, create the reinsurance program without a class
model.
○ Ranks: For ranks 1 and 2 of the reinsurance program, enter the master treaties AUSG_VTGQU and
AUSG_VTGSU that you created previously. Rank 2 covers the part of the risk that exceeds the quota
share liability. The quota share retention and retained line of the surplus treaty are copied to the
unplaced risk of the next rank via retention control.
For rank 3, enter facultative cover. This is just a placeholder and controls whether proportional
facultative participations can be added to a cession group that references the corresponding
reinsurance program.
Do not define any retention control for facultative placeholders.
○ Structure of Reinsurance Program
Rank Reference Coverage Ref Rank Category Name Treaty Control Reten
Rank erence tion
1 0 Total liability 1 Treaty ausg_vtgqu Retention is

not included
2 1 Unplaced risk 1 Treaty ausg_vtgsu Retention is

not included
3 2 Unplaced risk 3 Proportional

facultative re
quirement
○ Status: INPRO
○ Currency and Exchange Rate Type: EUR and M
2. Confirm your entries for the ranks.


Defining the Cessions
You can now enter the cessions for the first two ranks. If you have defined the class model, you can enter
cessions for each class in the class model. If not, the cessions can be entered independently of class. In either
case, the total cessions must not exceed the maximum capacity of the master treaty.
1. To enter the details, double-click the rank. The RIP PROG1 Change: RIP Cession screen appears. Enter the
quota share percentage.
3. If you have not created a class model, enter the data specified below for class A.
Cession for Quota Share Treaty
Class Name Quota Share Percentage Maximum Liability
A Class A 100 10,000,000
B Class B 20 10,000,000
Cession for Surplus Treaty
Class Name Retained Line Number
A Class A 1,000,000 7
B Class B 500,000 8
4. Set the status to “Processing Completed”.

4.11.5 Example: Creating Portfolio Treaties
Use
A portfolio treaty [page 92] (PTF treaty) is a dummy treaty with a structure that covers the entire risk portfolio.
In this example the PTF treaty must cover the structure and periods of the assumed participations.
After you have created the PTF treaty, you assign the reinsurance program to a section of the portfolio treaty.
Structure
In this example, the PTF treaty must have the following structure in order to cover the participations.

Business ness
PTF_VTG1 January 1, 2006 Fire World 10 EUR

- December 31,
9999
Procedure
1. Choose FS-RI: Reinsurance Basic System Treaty Create .

The procedure is similar to that for creating an assumed treaty.
Enter the required data:
○ Treaty: for example, PTF1
○ Treaty category: 3 (for portfolio treaty)
○ Nature of treaty: for example, PROBL
2. Choose . The Create Prop. Treaty PTF1: Header Data screen appears. Enter the required data: treaty
name and cedent (owner company).
Enter January 1, 2006 as the start date for the treaty.
3. Switch to the Periods tab page and enter the end date December 31, 9999.
4. Double-click the period. The Create Prop. Treaty PTF1: Sections screen appears. Enter values for the
required fields:
○ Section number
○ Section name
Confirm your entries.
5. Choose Create and enter the following data:
○ Class of business: for example, "Fire" (any additional classes of business must then be added on the
Classes of Business tab page after the other required entries have been made)
○ Reinsurance program: enter the reinsurance program you created previously
○ Area: for example, "World"
○ Business type: for example, "10"
○ Currency
○ Exchange rate type
Save your entries.
6. Go back two levels to the Periods tab page and change the status to a status that allows posting and is not
canceled.
7. Save your entries. Confirm the dialog boxes that appear by choosing Continue and OK.

4.11.6 Example: Creating Accumulation Groups
Use
Create an accumulation group using the data below as described under Creating Accumulation Groups [page
83].
For this example, create the accumulation group via the initial screen Manage Policy/Participation/Group.
Structure
Group category: “ACCUM”
Group name: accumulation group for fire
Status: a status that allows processing
Reason for change: NEW (you do not make this setting on the administration screen, but in the group after it
has been created)
Period: January 1, 2006 – December 31, 2006
4.11.7 Example: Creating Policies, Policy Sections, and

Participations
Use
For this example, you need to create two policies, each with one policy section.
The structure and period of the policies must fall within the scope of the risk covered by the portfolio treaty
(created in an earlier example).
The system determines the gross liability and remaining liability using the value type [page 59] assigned to the
class of business. For each class of business, you can define the respective value types for calculating the gross
liability and remaining liability in Customizing.
Procedure
1. Create the two polices

Create two policies using the following data. Use the instructions below.

Policy Period Classes of Area Business Type Line of Busi Currency
Business ness
Policy 1 January 1, Fire DE 10 EUR

2006 to De
cember 31,
2006
Policy 2 January 1, Fire DE 10 EUR

2006 to De
cember 31,
2006
1. Choose FS-RI: Reinsurance Risk Manager Contract Manager Manage Policy/Participation/

Group .
○ Policy: (if you do not enter a number, the system assigns a number internally)
○ Policy category: (choose a category for which the Assumed checkbox is selected)
3. Choose Create Policy. The Policy Header Administration: Policy Create screen appears.
4. Enter the data for the required fields:
○ Status: a status that allows processing
○ Reason for change: for example, NEW (new business)
○ Time rule: 24:00, policy start date: January 1, 2006
○ Policy end date: December 31, 2006
○ Company code chain: chain defined in Customizing that is relevant for this participation chain
○ Method: SUM (total)
○ Currency: EUR
○ Exchange rate type: M
○ Responsibilities: entries are based on the responsibilities you have created
Save your entries.
5. Choose the Create Policy Section pushbutton in the application toolbar.
6. Enter the data for the required fields:
○ Policy section number: 1
○ Policy section from: January 1, 2006
○ Valid to: December 31, 2006
○ Policy section category: for example, PROP (proportional coverage)
○ Status: for example, INPRO
○ Reason for change: for example, NEW
○ Underwriting date: January 1, 2006
○ Currency: EUR
○ Exchange rate type: M
○ Method: SUM (total)
Choose Enter to confirm your entries.
7. Enter the following data on the Create Policy Section screen:
○ Valuation date: January 1, 2006

○ Class of business: fire
○ Area: Germany
○ Leading currency: EUR
○ Leading rate type: M
○ Business type: 10
In the Statistics/Values table, enter the value 10,000,000 for the value type relevant for liability at
policy section level for policy 1 (6,000,000 for the policy section of policy 2). The value types relevant
for liability depend on the classes of business. These are defined in Customizing for FS-RI Reinsurance
under Basic System Treaty Classes/Lines of Business Edit Classes of Business .
8. This determines which field has to be filled in the table control in order to be considered by the liability
aggregation function. (Alternative path: Master Data Classes of Business Edit/Display ).
2. Assign the policies to the accumulation group.

In the next step you assign the two policies to your existing accumulation group “ACCUM” for the entire
period. You do this on the Group Assignment tab page, either in the policy or in the accumulation group
itself. This example describes how an assignment is made on the Group Assignment tab page.
Perform the following steps for each policy:
1. Select the policy on the Pol. Sec. Grouping tab page.
2. Select the policy section and choose the Create Group/Participation pushbutton.
3. Create the cedent participation.
Enter values for all the required fields and do not make any changes to the default entries:
○ Group number: any
○ Group category: cession with journal
○ Participation number: any
○ Participation type: proportional, for information
○ Risk carrier: the cedent specified in the assumed treaty
○ Participation period: January 1, 2006 to December 31, 2006
○ Signed line: 100%
3. Enter additional data for the participation.
1. Switch to the participation you have created by double-clicking the corresponding entry. Check the
data.
In the Statistics/Values table, you should see the signed line of 100%. The gross/remaining liability
calculated by the system is 10,000,000 (6,000,000 for the participation for policy 2).
2. Create your own participation.
Switch back to policy level using the “Policy Level” pushbutton in the application toolbar. Switch to the
Participation Grouping tab page. Select the cedent participation you have just created and choose the
Create Group/Participation pushbutton. Enter values for all the required fields and do not make any
changes to the default entries:
○ Group number
○ Group category: cession with journal
○ Participation number
○ Participation type: proportional facultative
○ Risk carrier: owner company
○ Treaty: assumed master treaty

○ Portfolio treaty: PTF treaty
4. Switch to the participation you have created by double-clicking the corresponding entry. Check the
data.
In the Statistics/Values table, you should see the signed line of 100%. The gross/remaining liability
calculated by the system is 10,000,000 (6,000,000). Do not change the default entries for the
participation fields.
Alternatively: You can also copy policy 1 and change the values in the copied policy.
4.11.8 Example: Creating Prior Cessions (Optional)
Use
You can create prior cessions [page 127] if you want to reinsure part of the assumed liability manually before
the system automatically assigns the rest to the reinsurance treaties defined in the reinsurance program (using
the functions for cession group creation and cession calculation).
This section is optional is not taken into consideration in the later examples.
Procedure
Creating a Ceded Treaty to Cover Prior Cessions
Before you create a prior cession, you should have a treaty to which it can be assigned.
Create a treaty for this purpose (for which the Ceded checkbox is selected). Use the function for copying a
treaty [page 301] to copy the ceded quota share treaty you have already created.
1. As the source treaty, enter your quota share treaty (ausg_vtg_qu) and the corresponding period (from
January 1, 2006).
2. Enter a name for the target treaty (for example, vertrag_vorweg) and the period January 1, 2006 to
December 31, 9999.
3. A dialog box appears for selecting the entities to be copied. For this example, leave the default settings and
choose Execute to save the target treaty.
4. Open the new treaty (vertrag_vorweg) and enter a maximum liability of 1,000,000 and a quota share of
10% on the Quota Share tab page at section level.
6. Set the status of the treaty on the Periods tab page to a status that allows posting.
7. Save the treaty.
Creating and Assigning a Prior Cession
1. In POLICY1, switch to the Participation Grouping tab page.

2. Select your own participation.

3. Choose the Group/Participation pushbutton.
4. Enter values for all the required fields without changing the default entries:
○ Group number
○ Group category: prior cession
○ Participation number
○ Participation type: proportional facultative
○ Rank: 1
○ Reference rank: 0
○ Coverage reference: TOTLB (total liability)
○ Risk carrier: owner company (here: HR)
○ Treaty: treaty created above
○ Control retention: IGNOR (retention is not included)
6. Go to the participation you have just created and check the data. In the Statistics/Values table, you should
see the signed line of 50%. The gross/remaining liability calculated by the system is 5,000,000.
7. Do not change any of the default entries for the participation fields.
4.11.9 Example: Editing Defaults for Cession Calculation

Criteria (Optional)
You can set default values for Extension Service fields that have been defined for certain tables relating to
cession group creation. To do this, you need to make the corresponding settings in the Customizing activity
Edit RIP Defaults for Cession Calculation Critieria.
For each field you want to be filled with a default value, you need to define the field and calculation rule to be
used for calculating the default value.
In Customizing for FS-RI Reinsurance choose Basic System Interfaces RM Connection RIP Settings
Edit RIP Defaults for Cession Calculation Criteria .
4.11.10 Example: Creating Cession Groups
Use
In this step you create the cession groups.

Prerequisites
● The status of the reinsurance program has the attribute Processing Completed.
● The status of the portfolio treaty allows posting and is reversed.
Procedure
1. Go to the accumulation level. Choose the Cession Group Creation pushbutton.

2. The system creates a cession group, which appears on the Participation Grouping tab page. When you save
the group, the system enters a sequence number for the cession group. (If you create cession groups at
accumulation level, the system consolidates the assigned participations and determines the liability totals
for the individual cession group periods).
3. Return to the “policy level”.
4. Switch to the Participation Grouping tab page and select the cession group created by the system by
double-clicking the group in the Groups table.
4.11.11 Example: Entering Extension Service Data for Groups

(Optional)
Switch to the Extension Service tab page within the cession group.
On the Change Group … screen, switch to the Extension Service tab page. In this example, the field you have
selected in Customizing (fire extinguisher, PML, and so on) can be edited manually, since no default values
have been defined. In other cases, the field may contain a default value, which you can either accept or change.
When it calculates cessions, the system compares the Extension Service data for the group with the class
model pattern “FIRE” defined for the reinsurance program. It determines class A or B, depending on the entry
in the Extension Service. This class and the corresponding cessions in the reinsurance program are then used
to generate the ceded participations.
4.11.12 Example: Calculating Cessions and Confirmation
Use
When it calculates cessions [page 95] the system assigns coverage to the assumed participations based on the
reinsurance program. The system generates the ceded participations automatically for the calculated liability.
The cession calculation is applied to the remaining liability after any prior cessions have been deducted. You
can adjust the remaining liability calculated by the system manually (= total liability amount).

Procedure
Cession Calculation
1. Switch to the “Liability Overview” tab page within the cession group.
2. On this tab page you see that the gross liability and remaining liability is 16,000,000.
3. Choose the Calculate Cessions pushbutton. This calls the cession calculation function for the entire group.
Result
The system has created ceded participations for the treaties specified in the reinsurance program. These are
displayed in the overview called Ceded Participations.
Liability of the participations created:
● Participation for quota share treaty: 10,000,000

● Participation for surplus treaty: 6,000,000
Confirm
Return to the accumulation level. Choose “Confirm”, and set the accumulation to a status that allows posting
and is not reversed.
Result
You have mapped the assumed and ceded business and are now ready to create accounts.
4.11.13 Example: Accounts
Use
This example shows how a premium of EUR 10,000 is posted to an account for the participation defined in the
previous steps.
For more information about the account and how it works, see Risk Manager Accounting Process [page 142].
Prerequisites
The status of the accumulation allows posting.
Procedure
1. Create an account
1. Choose FS-RI: Reinsurance Risk Manager RM Account Create/Edit/Display RM Account .

2. Choose the Create New Account pushbutton. The Create Accoun screen appears.
3. Enter the number of your own participation and confirm by choosing Enter.
4. Enter values in all the required fields.
○ Accounting year: 2006
○ Accounting period: YEAR
○ Original currency: EUR
5. Switch to the Postings tab page to create postings for the account. In this example, you are posting a
premium. Enter the relevant premium entry code and enter values for all the other required fields in the
table:
○ Amount in original currency: (EUR 10,000)
○ Revenue period: (January 1, 2006 – December 31, 2006)
2. Transfer to Basic System
If an account contains a share (involvement), you can transfer it to Basic System.
If you choose the Transfer to Basic System pushbutton, the system creates an account in Basic System
with the status “Pending”. You can then process the account further in Basic System.
3. Transfer to retrocession
You can use this function only if you have created at least one participation, and posting is allowed for this
participation. The inward account is transferred to the retrocession side and distributed to the ceded
participations. To do this, choose the Transfer to Re/Retrocession pushbutton.
4. Split and further process retrocession accounts
Switch to the “Assignment” tab page and double-click the retrocession account that has been created.
To distribute the account to the reinsurers involved in the master treaty, choose the Split pushbutton.
In this example the postings do not change. This is because the master treaty for the ceded participation
contains only one reinsurer with a signed line of 100%.
5. Transfer accounts generated by the "Split" function to Basic System
You then have to transfer the split accounts back to Basic System using the Transfer to Basic System
function. (You can navigate to the account for the share from the assignment table and then switch to
“edit” mode.)
 Note
You use the Calculate function if you have defined Risk Manager conditions in the ceded master treaty
or in the ceded participations. However, you must do this before the account is transferred to Basic
System. Once the account has been transferred, no changes are permitted.

5 Basic System
Use
FS-RI Basic System is the core of SAP Reinsurance Management for SAP S/4HANA (FS-RI) and is used to:
● Manage reinsurance treaties belonging to all known treaty types for ceded as well as assumed reinsurance
business
● Manage losses
● Manage reinsurance programs
● Create accounts for reinsurance-relevant policy sections
Features
Treaty Management
In FS-RI Basic System, you can create and edit assumed and ceded treaties, and link these to one another, to
automatically calculate the ceded business.
Loss Management
You can create losses, group losses in loss events, and create the corresponding accounts. Using the FS-RI
system, you can create postings from the ground up (FGU) and automatically calculate the burden on the
affected treaties. Interlocking clauses are also considered.
Account
In addition to the manual creation of account data such as premium and loss postings, the FS-RI system offers
you a multitude of automatic calculation options for creating automatic postings. These postings are
transferred to an integrated current account system for further processing in the payment transaction.
Forecast and Estimation
Using the FS-RI system, you can enter forecast and estimation figures and create a corresponding process for
reversed estimates.
Restrictions
You cannot manage individual risks and recognize accumulations in Basic System. To perform these functions,
you require FS-RI Risk Manager [page 33].

Basic System PUBLIC 193
5.1 Treaty
Definition
A reinsurance treaty in the FS-RI system maps a relationship between two or more business partners in the
reinsurance business.
The treaty details the partners involved according to the type and extent of their participation and liability; it
also describes the structure of the portfolio covered by the treaty.
Structure
For more information about the structure of an FS-RI treaty, see Treaty Level [page 202].
Integration
The data entered in the treaty forms the basis for almost every function in the FS-RI system. For example, the
treaty is integrated with the following objects:
● Other treaties
You can link treaties together. This means, for example, that an account created for an assumed treaty can
automatically trigger an account with the necessary postings in the ceded treaty. For more information
about the linking of treaties, see Mapping of Retrocession [page 325].
● Account
You can create accounts for each treaty to record premium payments, loss payments, and other payments
and post these to your current account system. For more information about accounts, see Account [page
347].
● Loss
When you enter a loss, you can assign this to a treaty that covers it. For more information about losses, see
Loss [page 611].
5.1.1 Treaty Classification
Definition
In the FS-RI system, reinsurance treaties are classified using the following criteria:
● Treaty class (Life/Non-Life)

● Treaty category (assumed, ceded, retrocession, portfolio definition, and so on)
● Nature of treaty (proportional obligatory, proportional facultative, proportional facultative/obligatory, non-
proportional obligatory, non-proportional facultative, non-proportional facultative/obligatory)

194 PUBLIC Basic System
● Treaty type (unique, such as quota share, surplus treaty, stop loss, and so on)
Use
For more information about how to create or change treaties and the characteristics typical for the treaty type,
see Creating Treaties [page 295].
For an overview of the structure of an FS-RI treaty, see Treaty Level [page 202].
A number of standard treaty types are predefined (default values). To change treaty types or define user-
specific treaty types, switch to external Customizing for Basic System.
5.1.1.1 Non-Proportional Treaty
Definition
Under a non-proportional (NP) reinsurance treaty, the partners involved agree that liability and premiums are
not proportionate to the business of the primary insurer, but are freely defined.
The reinsurer, or a group of reinsurers, assumes the liability for losses incurred above and up to a specific
amount.
Use
Non-proportional treaties are used mainly in the form of the following treaty types:
● Excess of loss
● Excess of loss per accumulation
● Stop loss
Structure
You can differentiate between a proportional and non-proportional treaty in the Nature of Treaty field in the
treaty header.
The NP Liability, NP Premium, Installment Schedule [page 268] and Reinstatement Schedule [page 270] tab
pages at section level contain the main data for the non-proportional treaty.
You can enter a great deal of data as a share of the gross premium or of the entire layer. The system then
breaks down this data based on the values in the Protected Share or Coinsurance fields.
Non-Proportional Liability
The system calculates "our share" of the liability as follows: our share = amount x protected share x signed line

You must always fill the amount fields for 100% of the treaty. In the case of a ceded treaty, the Our Share field
shows the share for the role of cedent only.
Interlocking
The system supports interlocking provisions between underwriting years and sections in non-proportional
treaties. You enter the type of interlocking on the Header Data tab page under Additional Data.
On the NP Liability tab page in the Liability Data table, you indicate which LUDs [page 272] are relevant for
interlocking.
For more information about calculating the interlocking effect in the account, see Interlocking [page 379].
Multiline and Multiyear
Limits that apply across periods and sections are supported for non-proportional treaties. On the Header Data
tab page under Additional Data, you specify whether a multiline limit (for all sections) or a multiyear limit (for all
periods) has been agreed for the treaty. You can enter the corresponding liability amounts on the LUD tab page
at the highest level in the treaty.
For more information about multiline and multiyear liabilities, see Multiline and Multiyear Liabilities [page 369].
Non-Proportional Premiums
Non-proportional premium data can be read by a background job. The adjustments for reinsurance shares can
be generated in this way. For more information, see Non-Proportional Premium [page 272].
The system calculates the XL premium as follows:
● For a fixed installment: subject premium x fixed installment

● For a fixed premium: fixed premium
● For a sliding scale installment: subject premium x minimum installment
The system then calculates the rate on line (ROL) from the XL premium as follows:
● If the liability amount is entered on the NP Liability tab page:

(XL premium/liability amount from NP liability) x 100
● If the liability percentage is entered on the NP Liability tab page:
(XL premium/(subject premium x liability percentage from NP liability)) x 100
○ If the liability amount and liability percentage are entered on the NP Liability tab page:
Liability amount from NP liability > (liability percentage from NP liability x subject premium):
(XL premium/(liability percentage from NP liability x subject premium)) x 100
○ Liability amount from NP liability <= (liability percentage from NP liability x subject premium):
(XL premium/liability amount from NP liability) x 100
● If an unlimited liability is defined in the non-proportional liability details, nothing is displayed here.
The system calculates the pay back from the reciprocal value of the ROL:
pay back = (1/ROL) x 100
If an unlimited liability is defined in the non-proportional liability details, nothing is displayed here.

5.1.1.1.1 XL fca Treaty
Definition
An XL fca treaty is a non-proportional reinsurance treaty for a common account (fca). This means that the
cedent has concluded a second reinsurance treaty, which includes not only its retention but also the
participation assumed by the reinsurers of a reinsurance treaty.
For the reinsurer, this treaty has the same effect as a retrocession made by the reinsurer for its own account,
but is also valid for all partners involved in the portfolio for the treaty.
An XL fca treaty requires the approval of the reinsurers involved. If the cedent is planning to conclude an XL fca
treaty, it must notify the reinsurers and inform them of the conditions. The reinsurers can decide if they want to
participate or they can be required to do so, depending on the treaty.
If the reinsurer has a share in the XL fca, it has to pay a part of the premium according to its share of the risk
and receives pro rata loss payments in return. The payment transactions are carried out via the cedent. A
reinsurer participating in the XL fca treaty does not usually know which reinsurers of the covered treaty are
participating.
Stop loss reinsurance can also be agreed as coverage for a common account.
Structure
Attributes of an XL fca Treaty
● A non-proportional treaty in which the XL fca checkbox is selected.

● For ceded business, the master treaty and XL fca treaty must have the same direction.
● The structure of the section in Basic System must match the structure of the XL fca section. The structure
comprises the class of business, area, business type, and line of business (if the line of business has been
defined as a structural parameter in Customizing).
● The period start date of the master treaty must fall within a period of the XL fca treaty.
Ceded Master Treaty Covered by XL fca (XL fca for the Primary Insurer)
If the master treaty is a ceded treaty, you must create a separate FS-RI treaty for the corresponding non-
proportional cover. In this case, you enter only the treaty number and section number for this coverage in the
master treaty. All other fields are locked.
Assumed Master Treaty Covered by XL fca (XL fca for the Reinsurer)
If an assumed treaty is covered by an XL fca, you must specify this in the relevant section.
Assumed XL fca Treaty
If you, as the reinsurer, transfer coverage by means of an XL fca treaty, you must create an assumed non-
proportional treaty and select the XL fca checkbox.
Special Features of XL fca Premium Data
You can enter the usual premium data for non-proportional treaties. However, the calculations supported by
the system are restricted (for example, the system cannot calculate the advance premium from the installment

schedule). In addition, you can enter a currency (provided you have defined this in the currency split table) and
exchange rate type, as well as the number of layers in the XL fca treaty.
5.1.1.2 Proportional Treaty
Definition
In proportional reinsurance, the participation of the reinsurer in contractually agreed risks, based on one
insurance policy or on the entire in-force business, is expressed by a variable or fixed rate (usually as a
percentage).
Once entered, this rate determines the reinsurer’s participation in the sum insured (liability), in the assumed
direct insurance premiums, in any loss payments to be made, and in any possible subrogation revenues.
Proportional reinsurance is divided into quota share and surplus reinsurance.
In the case of quota share reinsurance, the reinsurer assumes a fixed percentage rate of all the policies for a
certain class of business. This percentage rate does not fluctuate for the duration of the treaty and also
determines how premiums and losses are split between the partners involved.
In the case of surplus reinsurance, the reinsurer participates in only those ceded risks for which the sum
insured exceeds a certain amount (known as “retention”). The reinsurer’s share of all premiums and losses is
calculated from the ratio of sum insured to retention. The reinsurer’s obligation to assume risks is limited by a
number of “lines” (multiples of the retention covered by the surplus treaty).
Structure
Key Data for All Proportional Sections
The Quota Share tab page at section level contains all the data required for proportional treaties (quota share
or surplus). Depending on the treaty type, the system displays additional data for the quota share or surplus
treaty. The data for a quota share treaty comprises the quota share cession percentage, maximum liability
amount, Unlimited checkbox, estimated subject premium (EPI), calculation base, underwriting limit, Part Of
field, liability basis, and RI capacity. The data for a surplus treaty includes the retained line, the number of lines,
the Unlimited checkbox, the estimated subject premium (EPI), the calculation base, the underwriting limit, the
liability basis, and the RI capacity.
To enter amounts, you must enter a currency in the section.
Key Data for Quota Share Sections
The following key data applies if the treaty section is a quota share section:
● The Quota Share Percentage is based on the part of the assumed business relevant for this quota share and
shows the amount of the share that is reinsured by this treaty (for example, the quota share cession is
40%). When you create facultative/obligatory cover as a quota share, you must always enter 100% in this
field. You then enter the treaty capacity in the Maximum Liability field.
● The Part Of field denotes the share to which the quota is allocated. If, for example, a quota share already
covers a portfolio, you must enter 100 minus the (prior) quota cession in the “Part Of” field for any
subsequent quota. So, if the (prior) quota share is 60%, the subsequent quota share is 40%.

● The Maximum Liability Limit field contains the maximum amount (sum insured) to be reinsured through
the quota share. This value can also be related to one year. In this case, the maximum liability limit is also
called the maximum annual liability.
● The Unlimited checkbox indicates whether the treaty has unlimited liability. If you select this checkbox, you
cannot enter a maximum liability for the quota share cession. This field is typical for quota shares in the
areas of general liability and vehicle liability.
● The Underwriting Limit field refers to the maximum amount of a sum insured in terms of a risk or a PML
that the cedent can introduce for reinsurance purposes.
Key Data for Surplus Sections
The following key data applies if the treaty section is a surplus section:
● The Retained Line field specifies the absolute liability amount up to which the cedent is liable (retention).
● The Number of Retained Lines field specifies the RI capacity. The amount of RI capacity is then calculated
from the retained line and the number of lines.
● The Underwriting Limit field refers to the maximum amount of a sum insured in terms of a risk or a PML
that the cedent can introduce for reinsurance purposes.
5.1.1.3 Connecting Treaty
Definition
A treaty that, in the case of intra-company retrocession, synchronously maps the ceded business of the ceded
group company and the assumed business of the reinsured company.
Use
You use a connecting treaty to map the business relationship between the two companies in a single treaty,
instead of having a separate treaty for each company. This reduces your project outlay and prevents
inconsistencies.
Prerequisites for Use
● The cedent and reinsurer are both owner companies in different company codes.
● If you are working with FS-CD, the two company codes must belong to the same company code group.
● Some Customizing settings for company codes must be the same. For example, the settings for Current
Account System, Cross-Company Accounting, and Dialog Box Upon Release of Account in Customizing for
Basic System under Default Values Edit Defaults for Accounting .
● In Customizing for Basic System under Treaty Edit Treaty Category , you must assign only one
assumed treaty category as the treaty category for the connecting treaty, using the Area field. This is
necessary for account determination in current accounts.
● You have the necessary authorizations in the company code not only for the ceded part of the treaty but
also for the assumed part.

Structure
A connecting treaty is always a ceded treaty, for which you have set the Generate Accounts for Assumed
Business checkbox in the treaty involvement.
If you want to use the treaty in Risk Manager in a reinsurance program so that the connecting participation is
created automatically by the system, the following conditions must also be met:
● The Account Transfer from RM checkbox has been selected.

● The Create Assumed Business Side in Risk Manager checkbox has been selected.
● Only one reinsurer participates in the treaty.
● The reinsurer, who is the owner company with a company code that is different to that of the treaty header,
is continuously 100% involved in all periods and sections.
As soon as a connecting treaty has been entered in a reinsurance program, you cannot change the Create
Assumed Business Side in Risk Manager checkbox.
For more information, see Obligatory Connecting Treaties in the Reinsurance Program [page 104].
Integration
Account
For more information, see Accounts for Connecting Treaties [page 200].
Retrocession
The connecting treaty maps retrocession on the ceded side. This also applies for specific retrocession, which
means you can use the Specific Retrocession Treaty checkbox under Control Data on the treaty header data tab
page.
On the assumed side of the connecting treaty, you use section-based retrocession [page 325] or treaty
calculation rules [page 329] to define other types of specific retrocession.
Background Jobs
The background job Adjustment After Changing Signed Line [page 550] only includes the side belonging to the
source company code.
5.1.1.3.1 Accounts for Connecting Treaties
Use
When you create an account for a connecting treaty, you need only create the account for the ceded side. The
system creates the account for the assumed side when it releases the ceded account as its copy. When it posts
the data to the current account system, the system adjusts the plus/minus signs for the assumed account.

Features
Derivation Rules
The system calculates derivation rules only after the release of an account, because these may be different on
the ceded and assumed side.
Automatic Release
In Customizing you can specify whether the system releases the assumed account immediately or whether you
release the account manually at a later date or using a background job.
Deleting and Reversing Accounts
When you reverse [page 368] or delete [page 357] an account on the ceded side for which equivalent accounts
exist on the assumed side, the system also reverses or deletes the accounts on the assumed side. (Accounts
that have already been released are reversed; accounts that have not been released are deleted).
You cannot delete or reverse accounts created on the assumed side by means of a connecting treaty without
deleting or reversing the corresponding account on the ceded side.
Assumed Accounts
The system can create assumed accounts in a connecting treaty only when you release a ceded account. You
cannot manually create or copy an assumed account.
Transfer Account Currency as Original Currency
You can define in Customizing for FS-RI Reinsurance under Basic System Default Values Edit Defaults for
Accounting (using the Transfer to Original Amount and Currency (Transfer) checkbox) whether when you
release an outward account belonging to a connecting treaty the system transfers the following data to the
“Original Amount” and “Original Currency” fields in the inward account:
● The original amount and currency

● The amount posted and currency
If you want to transfer the account currency as the original currency and the currency check has been
activated in the system (Transfer to Original Amount and Currency (Transfer) and “Currency Check”
checkboxes have been set), when you release the accounts in Basic System the system checks whether the
currency split of the corresponding master treaty contains the account currency as the original currency.
In the event of an error, the system cancels the release of the account and displays the corresponding error
message.
Furthermore, when you set a connecting treaty to “Posting Allowed” in Basic System, the system checks
whether the currency split of the master treaty contains the account currency as the original currency and, if
necessary, it displays a warning.
5.1.1.4 Statistical Treaty
A statistical treaty is a treaty that does not represent a relationship between business partners in the
reinsurance business but serves only statistical purposes, for example it is used to define portfolios.
For the partner involved, it is enough to enter the treaty cedent, which is usually the owner company.

5.1.2 Treaty Level
Definition
A treaty level represents a part of the treaty in which you enter specific data. The treaty is divided hierarchically
into different levels. At most levels the data is distributed on several tab pages.
Use
To switch from a higher treaty level to a lower one, choose the relevant tab page and double-click the table row
containing the object to which you want to branch.
To switch from a lower treaty level to a higher one, choose .
Structure
Overview of the Treaty Structure
The figure below shows how the different levels of an FS-RI treaty are linked together.

● The header data contains all treaty data that is independent of the period. You can branch from the treaty
header to the individual periods of the treaty.
● Periods divide the treaty into time periods. The hierarchy below the periods contains information about the
treaty specifications (for example, sections, participations, conditions, and partners involved, which may
vary from period to period).
● You define the area of validity of the treaty under sections by entering information such as classes of
business, areas, business types, currencies, and lines of business.
● Under participations you define the share of the treaty held by the various business partners involved and
linked treaties.
● You can enter insurance-specific conditions, such as profit commission, under conditions.
Path to Individual Features
The following table shows the level on which you enter a specific feature.
Information Level
Treaty class (Life/Non-Life) Choose the corresponding initial screen in the treaty
Treaty category (assumed, ceded, and so on) Treaty header (determine before you create the treaty; you
cannot change this after the treaty has been created)
Nature of the treaty (proportional/non-proportional and Treaty header (determine before you create the treaty)
obligatory/facultative)
Treaty type (for example, quota, XL, SL) Can be selected when you create a section
5.1.2.1 Partner Involved
Definition
The partner involved is the company participating in the reinsurance treaty, for example, the cedent, reinsurer,
retrocessionaire, or broker. Your own company (the owner company) is also managed in the FS-RI system as a
partner involved.
Use
You define the companies participating in the treaty, and the type and extent of their involvement, in the
partner involved data.
In special cases, you can specify that a different treaty participates in a treaty. For more information, see
Participating Treaty [page 328].

Structure
You can find an overview of the partners involved on the Partners Involved Header tab page at treaty header
level, or on the Partners Involved tab page at period level. Information about individual partners are found one
level down at partner involved level.
The Shares and Broker tab pages at period level display the form and share of participation in the treaty of a
partner involved.
Details of Assumed Treaties
In the case of assumed treaties, the partners involved are usually the owner company (reinsurer) and the treaty
cedent. However, you can also enter shares for other partners if the information is available. You can deactivate
this option in external Customizing for Basic System under Default Values Edit Defaults for the Share
Level .
The owner company can be created in the treaty only as a reinsurer and not as a cedent. Exceptions to this are
pseudo assumed treaties, portfolio treaties for defining portfolios, and statistical treaties.
Details of Ceded Treaties
In the case of ceded treaties, you are more likely to have several partners involved/shares, in particular more
reinsurers, which can be processed in the system (by the accounting functions).
When you create a treaty, you can let the system create the required shares automatically.
Integration
Only companies that you have created in SAP Business Partner and have the corresponding role can be
selected as partners involved.
In external Customizing for Basic System under Default Values, you can define defaults for fields for partners
involved and shares.
5.1.2.1.1 Working with Cedents
Use
You want to create a treaty and accounts but are not yet certain of the cedent or have not created the cedent in
SAP Business Partner.
Features
Creating Treaty and Accounts Without a Cedent

You can create a treaty without entering a cedent, but you cannot set this treaty to a status that allows posting.
You can also create accounts for a treaty without a cedent, but you cannot release these accounts. When you
create a cedent for the treaty, the system enters this cedent in the relevant accounts.
If the treaty was saved without a cedent, this can be entered at a later date on the Partners Involved tab page.
Temporary Cedent
If you have entered a temporary cedent, you can change this cedent in the treaty on the Partners Involved tab
page if the following criteria are met:
● None of the treaty periods are or were set to a status that allows posting.
● You have not released an account for the treaty.
If you have entered a cedent, you must also enter a cedent in every account for the treaty. You can create an
account without a cedent only if the treaty does not have a cedent.
Use of Multiple Cedents
You can create multiple partners involved in the role of “Cedent” in an assumed treaty. This means that you can
distribute participations or their validity periods to different cedents in an assumed treaty.
The option of entering multiple cedents in an assumed treaty affects the Cedent field in the treaty header.
If there are already multiple cedent involvements in the treaty but the treaty has not yet been saved or postings
cannot be made to the cedent in the header, then the Cedent field is still ready for input at treaty level.
If the cedent entered in the header is changed, the corresponding involvement is also changed provided the
cedent does not exist in another involvement. If the cedent is changed in the header and the new cedent
already exists in another involvement then the entry is copied over.
At least one cedent must be valid at any time during the term of the treaty or during a settlement period. You
can control this by entering validity period for cedents in the participations [page 206].
5.1.2.1.2 Changing the Cedent or Adding the Cedent

Retrospectively
Use
You want to create a treaty and accounts but are not yet certain of the cedent or have not created the cedent in
SAP Business Partner.
Features
Creating Treaty and Accounts Without a Cedent
You can create a treaty without entering a cedent, but you cannot set this treaty to a status that allows posting.
You can also create accounts for a treaty without a cedent, but you cannot release these accounts. When you
create a cedent for the treaty, the system enters this cedent in the relevant accounts.

If the treaty is saved without a cedent, this can be entered at a later date on the Partners Involved tab page.
Temporary Cedent
If you have entered a temporary cedent, you can change this cedent in the treaty on the Partners Involved tab
page if the following criteria are met:
● None of the treaty periods are or were set to a status that allows posting.
● You have not released an account for the treaty.
If you have entered a cedent, you must also enter a cedent in every account for the treaty.
You can create an account without a cedent only if the treaty does not have a cedent.
5.1.2.1.3 Working with Participations
Use
You can enter partner involved shares for a treaty or a treaty period on the Participations tab page.
You can enter these shares in percent or as the numeric part of the total number of parts.
Features
You can use the following share categories.
Share Category Name Description
SL Signed line Used for reinsurer’s shares, specifies

the underwritten share, used by the FS-
RI system when it splits accounts.
NP Not placed Used for unplaced shares in ceded trea

ties, used by the FS-RI system when it
splits accounts.
$PL Placed Used for brokers shares, denotes the

placed broker share of a treaty.
$CP Cedent participation Used to denote the validity period for a

cedent participation.
In Customizing you can manage other statuses to denote written lines or broker orders, for example.
 Note
The participation type “$CP” is available for assumed treaties only.

A cedent participation is therefore only valid if there is no share or if there is an entry with participation type
“$CP”.
You can restrict the validity of cedents using the valid-from date of the participation.
A cedent participation can be marked as “invalid” if it is assigned a status that does not allow posting.
If you want to set a treaty period to a status that allows posting, there must be at least one cedent with a valid
status at all times during the period.
You can enter the partner involved shares in percent or as the numeric part of the total number of parts.
5.1.2.1.4 Working with Partners Involved
Use
This section gives you an overview of the functions used to work with partners involved.
Prerequisites
You have created the partner involved as a business partner and assigned it the appropriate role.
Features
You can find an overview of all partners involved for the treaty on the Partners Involved Header tab page at
treaty header level.
You can find an overview of the partners involved for a certain treaty period on the Partners Involved tab page at
period level.
To view the data for a specific partner involved, double-click the relevant entry on one of these two tab pages.
You can create and delete partners involved at period level only.
For more information about navigating in the FS-RI system, see Treaty Level [page 202].
Editing Partners Involved
Create On the Partners Involved tab page at pe You can enter the involvement number
riod level: (the number of the business partner
share) only when you create the busi
● Create
ness partner.
● OR: Select Edit Create

Change Partners Involved If you branch from the treaty header

(independent of the treaty period) to
the Partners Involved tab page, and the
partner involved is valid for several peri
ods, the system selects the most recent
period with the status Posting Allowed
and Not Canceled as the treaty period
for processing. If no such period exists,
the system selects the most recent pe
riod for which the partner involved is
valid.
 Caution
You can change the treaty cedent
only if you have not set the treaty to
a status for which posting is al
lowed.
Display Partners Involved
Delete On the Partners Involved tab page at pe You cannot delete a partner involved if it
riod level: is used in:
● Delete ● Accounts with postings
● OR: Select Edit Delete ● Result-independent conditions or

portfolio rules for the master treaty
Entry
● A reinsurance program assigned to
portfolio treaties with the same
partner involved
● A portfolio treaty used in Risk Man
ager
● Postings resulting from the deposit
rules
● Compensation rules in another
treaty
To delete a partner involved from all

parts of the treaty, you must delete it
from all periods.

5.1.2.1.5 Broker
Definition
The broker acts as an intermediary between the partners involved and receives a commission (brokerage) for
this.
Use
If you handle business with the partner involved through a broker, you must specify this in the treaty. In non-
proportional and stop loss treaties, the system then calculates the brokerage in the account. You can also enter
a co-broker for a broker.
Structure
Broker Is Business Partner
You must create a broker or co-broker in SAP Business Partner with the role “Broker”.
Broker Is Partner Involved
You must create the broker as a partner involved. If you are not able to do this when you assign the reinsurer to
the broker, the system automatically creates the broker as a partner involved.
Broker Share
You enter the broker’s share in the treaty or treaty section on the Participations tab page.
Participation of Reinsurer Arranged Through a Broker
If the participation of a reinsurer is arranged through a broker, you enter the reinsurer as a partner involved and
enter the broker on the Partners Involved Header tab page.
You enter the partner’s share in the treaty or section on the Participations tab page at period level. You can
enter this as a share of the entire treaty or as a share of the broker share or retention.
Brokerage
You enter the brokerage as a result-independent condition on the tab page of the same name. In the
Involvement field, enter the partner involved to which the broker is assigned.
Co-Broker
You define a co-broker as a co-leading partner of the broker in the partner involved data on the Partners
Involved tab page. You can also define the co-broker as the payment partner for an account; the system then
calculates the co-broker commission as a result-independent condition.

5.1.2.1.6 First- and Second-Level Risk Carrier
Definition
In the FS-RI system, the first-level risk carrier is the retrocessionaire for the reinsurer or retrocessionaire
participating directly in the treaty.
The second-level risk carrier is the retrocessionaire for the first-level risk carrier.
Use
If you know the retrocessionaires for your partner involved, you can enter these in the system, together with the
amount of your shares. The system does not evaluate this data but the information may help you avoid
unknown accumulations, for example.
You can also use the first-level risk carrier to define the retention.
Structure
You enter first-level risk carriers on the Risk Carrier 1 tab page at partners involved level. If you double-click an
entry for a first-level risk carrier, you branch to the second-level risk carrier.
When you delete a first-level risk carrier, the system also deletes all assigned second-level risk carriers.
5.1.2.1.7 XL fca Partner Involved
Definition
An XL fca treaty is a non-proportional reinsurance treaty for a common account (fca). This means that the
cedent has concluded a second reinsurance treaty, which includes not only its retention but also the portion of
the risk assumed by the reinsurers of an obligatory reinsurance treaty. For the reinsurer, this treaty has the
same effect as a retrocession made by the reinsurer for its own account.
An XL fca treaty requires the approval of the reinsurers involved. If the cedent is planning to conclude an XL fca
treaty, it must notify the reinsurers and inform them of the conditions. The reinsurers can decide if they want to
participate or they can be required to do so, depending on the treaty.
If the reinsurer (or one of the reinsurers) has a share in the XL fca treaty, it has to pay a part of the premium
from the first treaty and receives pro rata loss payments from the XL fca treaty if a loss occurs. The payment
transactions are carried out via the cedent. A reinsurer participating in an XL fca treaty does not usually know
which other reinsurers are participating.

Use
An XL share is the share that the reinsurers participating in a reinsurance treaty (usually a proportional treaty)
want to have protected by the XL fca treaty, or the share that is already protected. If the XL fca treaty is
obligatory, the share protected by the XL is the same as the share in the master treaty. If the XL fca treaty is not
obligatory, the protected shares can differ from the shares in the master treaty.
Structure
You manage the XL shares of a reinsurer on the XL Share tab page at partner involved/share level.
For each XL share, you assign the following: the protecting XL fca treaty to which the reinsurer share has been
assigned and the share in % that indicates the extent to which the reinsurer in the master treaty wants to be
protected (or is already protected) by the XL fca treaty.
This information is important when the accounts are generated for the treaties, since the amounts in the XL fca
treaty have to be assigned the opposite plus/minus sign.
The XL fca treaties you enter must be in the same company code as the master treaty. Once you have entered
the XL fca treaty, the field is locked.
XL shares must not exceed 100%.
 Note
The system does not include the XL fca data in the account.
5.1.2.2 Treaty Period
Definition
A treaty period subdivides a treaty into sections that represent different periods of time. Sections and
conditions may vary from period to period.
Use
Almost all treaty data is period dependent. You usually create one period for each treaty year.
Period Status
The status specifies the processing status of the treaty in this period. Standard statuses include “Create”, “In
Process”, “Reversed”, and “In Force”.
You can define customer-specific statuses in external Customizing for Basic System under Treaty Define
Statuses .

You can also define one or more successor statuses for a status that can be applied to a treaty period.
If a treaty period has a status for which you have defined at least one successor status, when you change the
treaty period status the system checks whether you have selected a valid successor status.
If a treaty period is assigned a status for which you have not defined a successor status, you can assign any
status you want to the treaty period as the next status.
The definition of this kind of successor status allows you to map the technical processes relating to treaty
changes in more detail and to avoid unwanted status changes to treaty periods.
When you set and save the status of a period to “In Force” (posting allowed), the system runs various validation
checks.
For example, it checks that:
● The shares of the reinsurer or broker amount to 100% in assumed retrocession treaties and ceded
reinsurance treaties. This check is not performed for assumed retrocession treaties.
● All the treaty types in the sections match the nature of treaty in the treaty header. ·
● All the classes of business in an assumed treaty also exist in the assigned retrocession treaty.
● All the areas in an assumed treaty also exist in the assigned retrocession treaty.
● All the business types in an assumed treaty also exist in the assigned retrocession treaty.
● All the lines of business in an assumed treaty also exist in the assigned retrocession treaty if the
appropriate settings have been made in the Customizing activity for lines of business.
The system runs the checks between assumed and retrocession treaties only if stipulated by the Customizing
settings. If an error occurs during the check, the system displays an overview of all the error messages.
When you set the status of the current period to a status that is canceled, the system fills the end date in the
treaty header with the end date of this period.
If the setting of a treaty period to a status causes performance problems because of a large and complex data
structure, you can set this status in the background using a background job. For more information, see Setting
of Periods to “In Force” (Posting Allowed) [page 213].
Structure
The period header is found at treaty header level on the Periods tab page. You can edit sections, participations,
conditions, and other treaty-related data at the detailed level of the period and in the underlying levels.
5.1.2.2.1 Working with Treaty Periods
You can use the following functions to edit treaty periods.

Create Enter the required data for a period on When you create a treaty, the system
the Periods tab page at treaty header automatically creates a period that be
level and choose Enter . gins on the treaty start date and covers
one calendar year.
Edit Switch to the Periods tab page at treaty You can edit a period only if it has a sta
header level, double-click or select the tus that does not allow posting.
period, and choose .
Copy See Copying Treaty Periods [page 302].
Delete Select one or more periods on the

Periods tab page at treaty header level
and choose .
5.1.2.2.2 Setting of Periods to “In Force” (Posting Allowed)
Use
When you set the status of a treaty period to In Force (posting allowed), the system performs a series of
checks. In the case of portfolio treaties in particular, this may cause increased runtimes and, in extreme cases,
timeouts. To avoid this, you can instruct the system to set periods to In Force in the background.
Prerequisites
If you want to set the status of non-portfolio treaties to In Force in the background, you must select the
SetInFrcBG checkbox ("Set Periods to “In Force” in the Background") in Customizing for Basic System.
However, a dialog box for background processing always appears when you set the status of a portfolio treaty
to In Force.
Features
When you save the status of a treaty to In Force, a dialog box appears in which you can select online or
background processing. If you select background processing, you cannot edit the treaty during processing.
If errors occur during background processing, the system saves the treaty along with the temporary changes in
the last status specified in the database. The system displays the result of background processing in a
message that appears on the screen and in a notification in SAP Office. The system documents any errors that
occur during background processing in transaction SM37 (Simple Job Selection).

5.1.2.2.3 Closing Periods and Shares
Use
In the treaty dialog, you can close periods and shares at treaty header and period level.
Prerequisites
● In Customizing under FS-RI Reinsurance Basic System Treaty Define Statuses , you have
defined the status “Closed” for participations and periods (by setting the Closed checkbox).
 Note
When you set the Closed checkbox, you can no longer set the status “Posting Allowed” or “Canceled”.
● All estimates have been reversed.

● All fund balances have been released.
● There are no pending Risk Manager and Basic System accounts.
● There are no open losses for the corresponding periods or shares and, therefore, no open reserves
assigned to a loss.
● There are no open reserves for the corresponding periods or share without a loss assignment.
Features
In the treaty dialog you can set the Closed checkbox for an entire period or for individual shares. After you have
set a status to “Closed”, you cannot make any changes on lower treaty levels or on the period level.
Closing Periods
When you save a closed status, the system checks whether the prerequisites listed above are met for each
period and calculates the reserve balances for premium and loss reserves without loss reference.
Closing Shares
You can set the Closed checkbox for the following participation types:
● Signed line (SL)

● Cedent participation (§CP)
● Placed (§PL) (for broker participations)
When you set the Closed checkbox for a share, the system checks whether all the entries for the relevant
section/share combination (all the validity periods for each combination of section and share) are closed. The
system sets the effective share to 0% and checks whether the prerequisites listed above are met.

If the checks do not result in errors, the system calculates the reserve balances for all the section/share
combinations being closed in the relevant period.
Result
If you have set the Clear LR (Clear Loss Reserves) checkbox in Customizing under FS-RI Reinsurance Basic
System Loss Program Control , the system displays the existing reserve balances in a separate dialog
box.
You can start the automatic clearing of the reserve balances by choosing the Clear pushbutton.
 Note
The balances are cleared even if postings to the period were previously not allowed.
The share being closed must have a status that allows posting.
The Clear pushbutton is not available in accounting year treaties.
If you have not set the Clear LR checkbox in Customizing under FS-RI Reinsurance Basic System Loss
Program Control , you cannot clear the reserve balances automatically. In this case, the system displays an
error message and terminates the save process. You have to clear the existing reserve balances manually so
that you can close the corresponding period or share.
5.1.2.2.4 Result-Dependent Condition
Definition
A condition whose validity and effect depends on the premium and loss development of the treaty. Examples
include a no-claims bonus or a sliding scale profit commission.
Use
In the following cases, you define a condition as a result-dependent condition or load the relevant condition
template:
● The validity of the condition depends on the premium development or loss record for the treaty period. An
example of this is a no-claims bonus that is only paid out if no losses are incurred for a treaty.
● The exact value of a condition depends on the premium development or loss record for the treaty period.
An example of this is a sliding scale profit commission. Here, the reinsurer pays a higher percentage of the
premium income back to the cedent as commission if its profit is higher than expected.
You can use the result of any calculation base or of any combination of calculation bases as the base value for
calculating the validity and value of a condition.

You can also define the amount of the posting generated by the condition as the combination of a value to be
applied with one or more calculation bases.
In a scaled condition, the amount of the value to be applied depends on the amount of the calculated base
value.
You can also define several conditions that are dependent on each other and that are processed with the
account in a set order.
You can restrict the validity of a result-dependent condition to an actual/estimate indicator.
Structure
Condition Contained in Treaty
You can find an overview of the result-dependent conditions for a treaty on the Result-Dependent Condition tab
page at period, section, and share level. You can find the entry screen for editing the individual conditions one
level below.
Condition Template
If you use a condition template, you do not have to enter frequently occurring conditions individually for each
treaty.
● You define templates for result-dependent conditions in the FS-RI initial menu under Basic System
Treaty Templates Result-Dependent Conditions . The template has the same structure as a condition
in a treaty, except you cannot enter data that depends directly or indirectly on the treaty. This includes
section, share, accounting unit, compensation rules, and comments.
● You load condition templates by choosing Load Template. You can then edit the condition as required for a
specific treaty.
Sections in a Condition
A result-dependent condition is defined by the following sections:
● Header data (Result-Dependent Condition tab page): The general area of validity for the condition.
● Agreed conditions (Result-Dependent Condition tab page): Basic data for the condition. Here you enter the
values and methods used by the system to calculate the condition and its rank.
● Carryforwards (Result-Dependent Condition tab page): This defines the carryforward process over several
years.
● Time limits (Result-Dependent Condition tab page): The time limits relating to the condition.
● Sliding scale definition (Result-Dependent Condition and Sliding Scale tab pages): Here you define the
values to be applied by a sliding scale. The sliding scale is generated automatically by choosing the Scale
pushbutton on the Result-Dependent Condition tab page.
● Compensation rules (Compensation Rules tab page): Rules relating to the combined evaluation of several
treaty sections or treaties as the basis for the result-dependent condition. For example, you can agree with
your partner involved on a profit commission from the gross profit of several treaty sections.
● Comment (Comment tab page)

Integration
You can calculate the resulting postings from the result-dependent conditions using a background job and post
these to the corresponding treaty sections. We recommend you schedule this background job periodically,
such as at the end of each period. For more information about the background job, see Calculate Result-
Dependent Conditions (Basic System) [page 539].
5.1.2.2.4.1 Examples of Result-Dependent Conditions
The following examples will help you define result-dependent conditions.
Example Contents
Profit commission based on occurrence year Profit commission based on the occurrence year; method
used to calculate the underwriting and occurrence years for
accounts
Profit commission based on underwriting year Profit commission based on the underwriting year; method
used to calculate the underwriting and occurrence years for
accounts
Profit commission with loss carryforward Profit commission with loss carryforward period of three
years and carryforward posting
Sliding scale commission in three period block (based on Definition of sliding scale; result-dependent conditions are
loss ratio) processed across several periods
5.1.2.2.4.1.1 Profit Commission Based on Occurrence Year
This example demonstrates how you map and process a profit commission in an assumed treaty based on the
occurrence year. Here, the profit commission is also based on the occurrence year.
Treaty Structure
Your treaty contains three periods (1998, 1999, and 2000) and a section with user-defined structural
characteristics, in which the occurrence year is set as the year basis for premiums and losses. You create the
profit commission as a result-dependent condition with the following data.
Agreed Conditions
Year Basis: “Occurrence Year”
Entry Code for Conditions: “2700” (or the entry code you use for profit commission)

Calculation Base 1: “7” (technical result)
Posting Condition: “GT” (positive)
Uniform Percentage: “8” (1998 period)
Uniform Percentage: “”12 (1999 period)
Percentage Calculation Base: “7” (technical result)
Account
1. The following premiums and losses occur during the term of the treaty. You create these as manual
postings in accounts.
Account for Accounting Year 1998
Occurrence Year Underwriting Year Posting Type Amount Posted
1998 1995 Premium 105
1998 1995 Loss 85
1998 1995 Premium 10
1998 1995 Loss 60
1999 1998 Premium 100
1999 1998 Loss 80
1999 1999 Loss 60
2000 2000 Premium 35
2000 2000 Loss 20
2000 1997 Premium 10
2000 1997 Loss 10

1998 1998 Premium 60
1999 1999 Premium 30
1998 1997 Premium 25
1998 1997 Loss 50
1998 1998 Premium 125
1998 1998 Loss -20
1999 1997 Premium 40
1999 1997 Loss 20
2000 2000 Premium 50
2000 2000 Loss 12
2. You release the accounts.

3. You run the Calculate Result-Dependent Conditions background job for this treaty, with the end of
accounting period 12/31/2002.
4. The system goes through each occurrence year and uses the postings released for each combination of
underwriting year/occurrence year/accounting year to calculate the accumulated premiums and losses,
the accumulated profit, and the accumulated profit commission. These are shown in the tables below in
the rows Premium (Total), Loss (Total), Profit (Total), and Profit Commission (Amount).
5. The system posts the delta from the total profit for the current year and from that of the previous year as
the delta posting for the profit commission (row "Delta"). If the total profit for a combination of
underwriting year/accounting year is zero or negative, the system determines whether positive amounts
from previous occurrence years are posted and offsets these so that the profit commission returns to 0. As
a result, the profit commission amount is up to date for each combination of underwriting year/accounting
year.
6. As the result of the background job, the system generates an account for each occurrence year in which a
profit commission is due. This account contains the final profit commission posting from the condition.
This is the last field in the Profit Commission row in the tables below. The underwriting year for the
generated account is the most recent underwriting year for accounts with postings relating to profit
commission. The accounting year for the generated account corresponds with the end date of the
accounting period for which you have run the background job.
7. In the summary of accounts for the generated accounts, check the individual detailed postings that led to
the result posted for the account.
Posting Data for Accounts for the Occurrence Year 1998 (Profit Commission 8%)

Underwriting 1995 1995 1997 1998 1998
Year
Accounting Year 1998 1998 2002 2001 2002
Premium Posting 105 10 25 60 125
Loss Posting 85 60 50 0 -20
Premium (Total) 105 115 140 200 325
Loss (Total) 85 145 195 195 175
Profit (Total) 20 -30 -55 5 150
Profit Commis 1.6 0 0 0.4 12

sion (Amount)
Delta 1.6 -1.6 0 0.4 11.6
Underwriting Year 1998 1997 1999 1999
Accounting Year 1999 2002 1999 2001
Premium Posting 100 40 0 30
Loss Posting 80 20 60 0
Premium (Total) 100 140 140 170
Loss (Total) 80 100 160 160
Profit (Total) 20 40 -20 10
Profit Commission 2.4 4.8 0 1.2

(Amount)
Delta 2.4 2.4 -4.8 1.2
Underwriting Year 2000 1997 2000
Accounting Year 2000 2000 2002
Premium Posting 35 10 50
Loss Posting 20 10 12

Premium (Total) 35 45 95
Loss (Total) 20 30 42
Profit (Total) 15 15 53
Profit Commission 1.5 1.5 5.3

(Amount)
Delta 1.5 0 3.8
5.1.2.2.4.1.2 Profit Commission Based on Underwriting Year
This example demonstrates how you map and process a profit commission in an assumed treaty based on the
underwriting year.
Treaty Structure
In your treaty, you have set the modes for premiums and losses to underwriting year. The treaty contains three
periods covering 1998, 1999, 2000, 2001, and 2002.
You create the profit commission as a result-dependent condition with the following data.
Agreed Conditions
Year Basis: “Underwriting Year”
Below Threshold: “LOSS” (loss)
Uniform Percentage: “15” (2000 – 2002 periods)
Account
1. The following premiums and losses occur during the term of the treaty. You create these as manual
postings in an account with the accounting year 2002. These are shown in the tables below in the rows
"Premium (Incr.)" and "Loss (Incr.)".

2. You release the accounts.
3. You run the Calculate Result-Dependent Conditions background job for this treaty, with the end of
accounting period 12/31/2002.
4. The system uses the postings released for each combination of underwriting year/occurrence year to
calculate the accumulated premiums and losses, the accumulated profit, and the accumulated profit
commission. These are shown in the tables below in the rows Premium (Total), Loss (Total), Profit (Total),
and Profit Commission (Amount).
5. The system posts the delta from the total profit for the current year and from that of the previous year as
the delta posting for the profit commission (row "Delta Posting"). If the total profit for an underwriting year
is zero or negative, the system determines whether positive amounts from previous underwriting years are
posted and offsets these so that the profit commission returns to 0. As a result, the profit commission
amount is up to date for each underwriting year.
6. As the result of the background job, the system generates accounts that contain the final profit
commission posting from the condition. This is the last field in the Profit Commission row. The underwriting
year for the generated account is the underwriting year for the underlying accounts. The occurrence year
for the generated account is the most recent occurrence year from the underlying accounts.
7. In the summary of accounts for the generated accounts, check the individual detailed postings that led to
the result posted for the account.
Posting Data for Accounts for the Underwriting Year 1998
Occurrence Year 1998 1999 2000 2001 2002
Underwriting 1998 1998 1998 1998 1998

Year
Premium (Incr.) 120,000,000 20,000,000 35,000,000 -10,000,000 125,000,000
Loss (Incr.) 100,000,000 50,000,000 20,000,000 25,000,000 -20,000,000
Premium (Total) 100,000,000 140,000,000 175,000,000 165,000,000 290,000,000
Loss (Total) 100,000,000 150,000,000 170,000,000 195,000,000 175,000,000
Profit (Total) 20,000,000 -10,000,000 5,000,000 -30,000,000 115,000,000
Profit Commis 2,000,000 0 500,000 0 115,000,000

sion (Amount)
Delta Posting 2,000,000 -2,000,000 500,000 -500,000 11,500,000
Occurrence Year 1999 2000 2001 2002
Underwriting Year 1999 1999 1999 1999
Premium (Incr.) 125,000,000 40,000,000 0 0
Loss (Incr.) 120,000,000 20,000,000 60,000,000 0

Premium (Total) 125,000,000 165,000,000 165,000,000 165,000,000
Loss (Total) 120,000,000 140,000,000 200,000,000 200,000,000
Profit (Total) 5,000,000 25,000,000 -35,000,000 -35,000,000
Profit Commission 900,000 4,500,000 0 0 (no account gener

(Amount) ated)
Delta Posting 900,000 3,600,000 -4,500,000 0
Occurrence Year 2000 2001 2002
Underwriting Year 2000 2000 2000
Premium (Incr.) 40,000,000 0 5,000,000
Loss (Incr.) 20,000,000 15,000,000 0
Premium (Total) 40,000,000 40,000,000 45,000,000
Loss (Total) 20,000,000 35,000,000 35,000,000
Profit (Total) 20,000,000 5,000,000 10,000,000
Profit Commission 3,000,000 750,000 1,500,000

(Amount)
Delta Posting 3,000,000 -2,250,000 750,000
5.1.2.2.4.1.3 Profit Commission with Loss Carryforward
This example demonstrates how you map and process a profit commission in an assumed treaty.
Treaty Structure
In the treaty, you have set the modes for premiums and losses to occurrence year. The treaty contains the
periods 1996, 1997, 1998, 1999, and 2000.
You create the profit commission as a result-dependent condition with the following data.
Agreed Conditions
Year Basis: “Accounting Year”

Below Threshold: “LOSS” (loss)
Uniform Percentage: “20”
Cut-Off/Run-Off
Loss Carryforward: “3”
Account
You create an account with the accounting year 2000 and enter the following posting data. Then you release
this account.
Original Posting Data
Entry Code Underwriting Year Occurrence Year Original Amount
1701 (Premium) 1996 1996 34,000
3100 (Loss Payment) 1996 1996 50,000
1701 (Premium) 1997 1997 60,000
3100 (Loss Payment) 1997 1997 60,000
1701 (Premium) 1998 1998 26,500
3100 (Loss Payment) 1998 1998 33,700
1701 (Premium) 1999 1999 15,000
3100 (Loss Payment) 1999 1999 5,000
1701 (Premium) 2000 2000 16,000
3100 (Loss Payment) 2000 2000 5,000
Next you calculate the result-dependent condition for 12/31/2000 using the Calculate Result-Dependent
Conditions [page 539] background job. The system creates a generated account.
Entry Code Underwriting Year Occurrence Year Original Amount
2700 (Profit Commission) 2000 2000 640

Calculation Method
The system calculates the profit commission as follows.
In the accounting year 2000, a loss of EUR 600 is entered for 1997. This loss is carried forward three years and
offset against the 2000 profit. A loss of EUR 7,200 incurred in 1998 is carried forward and offset in the same
way.
The 1999 profit is not sufficient to clear the losses incurred in 1997 and 1998 since all of this profit is “used up”
to clear the earlier, and prioritized, loss from 1996. This profit does not clear all of the 1996 loss, but the
remaining loss expires because the loss carryforward period was restricted to three years.
This process is set out more clearly in the following tables. In the first table, only the year 2000 is relevant (the
year for which you created the account).
Results from the Underwriting Years for Each Development Year
Underwriting Years
Development 1996 1997 1998 1999 2000 2001 2002

Years
1996 19,000 – – – – – –
1997 8,000 15,000 – – – – –
1998 1,000 11,000 -2,000 – – – –
1999 -14,000 -1,000 -1,500 10,000 – – –
2000 -16,000 -600 -7,200 10,000 11,000 – –
Losses Carried Forward (LCF) During the Development Years
Year 1996 1997 1997 1998 1998 1999 1999 2000 2000
Result -16,000 -600 -7,200 10,000 11,000
LCF from Old New Old New Old New Old New
Year
1 -16,000 -16,000 -16,000 -16,000 -16,000 -16,000 0 0
2 -600 -600 -600 -600 -600 0
3 -7,200 -7,200 -7,200 0
4 0 0
Total LCF 0 -16,000 -16,600 -23,800 -7,800

Year 1996 1997 1997 1998 1998 1999 1999 2000 2000
Total Re -16,000 -16,000 -23,800 -13,800 3,200

sult
Profit 0 0 0 0 640
Commis
sion
5.1.2.2.4.1.4 Sliding Scale Commission in Three Period Block

(Based on Loss Ratio)
You are a reinsurer and have agreed to pay your cedent back part of the gross premium in the form of
commission that varies according to profit margin. You determine the profit margin from the company’s
performance over three years.
Treaty Structure
You have a treaty containing the periods 2001, 2002, and 2003. You create the sliding scale commission in the
period 2001 as a result-dependent condition with the following data. Because you enter a block duration of
three years, the system enters the same conditions in the two following periods.
Agreed Conditions
Entry code for conditions: "2116" (or the entry code you use for sliding scale commission)
Calculation base 1: "11" (losses incurred)
Operator: "/"
Calculation base 2: "1" (gross premium)
Posting condition: "GT" (positive)
Percentage calculation base: "7" (technical result)
Block type: "1" (fixed)
Block duration: "3" (years)
Sliding Scale Definition
Enter the following values on the same tab page under Sliding Scale Definition:
Sliding scale: "m" (mean value)
Minimum percentage: "60"
Maximum percentage: "90"
The percentage is calculated by calculation base 1 [operator] calculation base 2 (in this case "losses incurred /
gross premium").

After you have made all your entries on this tab page, choose the Sliding Scale pushbutton. A dialog box
appears. For the minimum calculated percentage (60), enter an applicable percentage rate of 25%. For the
maximum calculated percentage rate, enter an applicable percentage rate of 10%. Enter "10" as the increment
for the calculated percentages. When you choose Continue, the system enters the following data in the table on
the Sliding Scale tab page.
Calculated Percentage Applicable Percentage
60 25
70 20
80 15
90 10
Account
Premium and Loss Payments
The following premiums and losses occur during the term of the treaty. You create these as manual postings in
an account, with the financial and accounting year 2003. Then you release the account.
Posting Data for Premiums and Losses
Entry Code Underwriting Year Underwriting Occurrence Year Occurrence Date Original Amount
Date
1701 (Premium) 2001 01/01 2001 01/01 EUR 50,000,000
1701 (Premium) 2002 01/01 2002 01/01 EUR 20,000,000
1701 (Premium) 2003 01/01 2003 01/01 EUR 30,000,000
3100 Loss 2001 01/01 2001 01/01 EUR 20,000,000
3100 Loss 2002 01/01 2002 01/01 EUR 40,000,000
3100 Loss 2003 01/01 2003 01/01 EUR 8,000,000
Sliding Scale Commission
After you have released the account for premiums and losses, you run the Calculate Result-Dependent
Conditions background job to calculate these conditions. The following values are displayed in the results log
for this background job.

Results Log
Interim Result Value
Result for calculation base 11 68,000,000 -
Result for calculation base 1 100,000,000
Total carried forward 0.00
Result of calculation base 1 [operator] calculation base 2 68.00 - %
The percentage (68.00%) lies within the scale limits. There

are no carryforwards.
The sliding scale results in an applicable percentage of

21.00%.
The system adds up the postings from all three periods based on the block definition.
The applicable percentage of 21.00% is the mean value for the value 68 calculated from the reference value
pairs defined in the sliding scale (calculated value 60 x applicable value 25 and calculated value 70 x applicable
value 20) according to the following formula:
x = AU + |(CU-y)|*|(AU-AL)|/|(CU-CL)|
Where:
x = actual applicable value
y = actual calculated value
AU = applicable value for next value above (upper limit of scale segment)
AL = applicable value for next value below (lower limit of scale segment)
CU = calculated value for next value above (upper limit of scale segment)
CL = calculated value for next value below (lower limit of scale segment)
Resulting Posting
The system calculates 21% of 32,000,000 (the result of the percentage calculation base Technical Result) and
then posts a profit commission of EUR 6,720,000.00. The system creates a new account for this posting that is
assigned to your treaty.
Result
You can view a condensed list of all accounts and postings for the treaty using the function Display Summary of
Accounts (/MSG/R_AE). You find this function on the initial menu under Basic System -> Account Display ->
Display Summary of Accounts.

5.1.2.2.4.2 Compensation Rule
Definition
If you use a compensation rule, when the system calculates a result-dependent condition it considers the result
of the current section and also the total result of a defined group of sections in the treaty or other treaties.
You can use compensation rules, for example, to prevent the reinsurer from having to pay a profit commission
to the cedent for a section, even if the reinsurer has made a loss from the total business with this cedent.
Use
You can create a compensation rule only if you have assigned the result-dependent conditions directly to a
share. When you create a compensation rule within a result-dependent condition, this condition is the main
condition of the compensation rule.
Prerequisites for the Use of Sections in a Compensation Rule
● All sections have the same treaty period.

● The owner company is involved in all sections. The owner company can also appear in different roles
(cedent, reinsurer).
● The partner involved of the owner company from the main condition is involved in all sections. Similarly,
the partner involved can also appear in different roles (cedent, reinsurer). The owner company and partner
involved can also be the joint reinsurer of a third partner involved.
● The treaty section to be assigned does not contain a result-dependent condition that uses the same entry
code as the main condition.
Structure
You can find an overview of the main compensation rules in a period on the Compensation Rules tab page at
period level.
You create a compensation rule at the detail level of the result-dependent condition.
You can also view the compensation rule in the participating sections. You can navigate from the participating
sections to the condition details of the compensation rules. The relevant conditions are flagged in the
participating sections with the entry Related Treaty on the overview screen for the conditions.
5.1.2.2.4.3 Result-Dependent Conditions in Life Treaties
Calculation Bases
You are permitted to use only “/” as the operator between calculation base 1 and 2.

Accounting Units
When the system processes the result-dependent condition using the Calculate Result-Dependent Conditions
background job, it evaluates the calculation bases 1 and 2 for all accounting units. When it determines the
resulting posting based on the percentage calculation base, it does this separately for each accounting unit.
 Example
You have a life treaty with a profit commission of 10% of the technical result. You make the following
postings to this treaty:
● EUR 20,000,000 premium to AU1

● EUR 15,000,000 premium to AU2
● EUR 5,000,000 loss to AU1
● EUR 7,800,000 loss to AU2
Using the calculation base Technical Result, the system returns the amount of EUR 22,200,000. It
distributes the resulting profit commission of EUR 2,220,000 to the accounting units and posts a profit
commission of EUR 1,500,000 to AU1 and EUR 720,000 to AU2.
5.1.2.2.4.4 Copying Result-Dependent Conditions
Procedure
1. On the Result-Dependent Conditions tab page at treaty period level, choose the condition you want to copy.
2. Choose the pushbutton.

3. Enter the required data in the dialog box.
4. The system checks whether the target condition already exists in this combination. If it does, the system
terminates the copying process.
5. The system copies the condition.
 Note
The system does not copy compensation rules because the copied condition may not fulfill the
prerequisites for these rules. The system copies the sliding scale only if this does not yet exist in the
database.

5.1.2.2.5 Result-Independent Condition
Definition
The validity and effects of result-independent conditions for a participation are independent of the premium
and loss development. Examples include result-dependent commission payments or a reinsurance tax with a
fixed percentage rate.
Use
Structure
For more information about the Result-Independent Conditions screen, see the documentation for Basic
System entitled Result-Independent Condition [page 114].
Validity Period
If you create a new condition of the same type, but with a different valid-from date, the system sets the valid-to
date of the previous condition to the valid-from date of the new condition. A condition is “of the same type” if
the category, rank, target entry code and usage are the same. All the other fields can differ between validity
periods.
The system performs validation checks to ensure that the validity periods for conditions of the same type do
not overlap. It also checks that the valid-to date for a condition is after the valid-from date, and that the valid-
from date is not blank if a value has been entered in the Valid-To field. The same applies if changes are made to
the validity periods in retrospect: the system always ensures that conditions of the same type do not have
overlapping validity periods, and that there are no gaps between the validity periods.
Minimum and Maximum Condition Amount
You can enter a maximum and minimum condition amount for each condition. These entries set an upper and
lower limit for the amount that is calculated for the condition. Therefore, the following applies: “minimum” <=
calculated condition amount <= “maximum”. However, these limits are for information only, and are not
processed by the system.

Integration
If you make changes to conditions after postings have already been made (as would be the case with short-
term cancellation), you can correct the postings by running the background adjustment job.
5.1.2.2.5.1 Validity Period of Condition
You can use the valid-from and valid-to date to restrict the effective period of a condition independent of treaty
periods. The start of the validity period must not be before the start of the period.
Dependencies
The validity periods must not overlap for the same condition, section, rank, share (involvement), and actual/
estimate indicator.
Condition Categories: Commission (COM), Other (MISC), Transfer (TRAN), Unearned Premiums (UEP)
In the case of these condition categories, the target entry code must be the same if two of these conditions
have the same:
● Category
● Rank
● Share
● Actual/estimate indicator
● But different validity periods
Condition Categories: Commission (COM), Other (MISC), Transfer (TRAN), Unearned Premiums (UEP)
In the case of these condition categories, two conditions must be distinguished by a different:
● Category
● Section
● Share (involvement)
● Validity period
● Entry code
● Accounting units
In this case, a different rank does not count as a distinguishing characteristic.

5.1.2.2.5.2 Differentiate Conditions by Share, Accounting
Unit, and Section
Use
You use the function Differentiate Conditions by Share, Accounting Unit, Section, and Actual/Estimate Indicator
to differentiate the exact value of a result-independent condition with the same category, rank, and validity
period according to the involvements, accounting units or sections with postings, or the actual/estimate
indicators.
For example, you can arrange that a commission that is usually 10% is only 8% for section 1.
Features
To create a differentiated condition, enter the condition several times with the same Category, Rank, Validity
Period, and Period (grouping criteria) and change only the area to which the condition is to apply (selection
criteria: Involvement, Accounting Unit, Section, Actual/Estimate Indicator) and the exact value (for example,
commission percentage).
If the grouping criteria are the same, the system creates one posting only. If two entries overlap, such as
“involvement 1, all sections” and “section 1, all involvements”, the system weights the entries in the following
order:
1. Involvement
2. Accounting Unit
3. Section
4. Actual/Estimate Indicator
 Caution
This selection rule applies to the specified selection criteria only. If you enter overlapping data for the
grouping criteria Category, Rank, Period, and Validity Period, the system creates several postings for the
same grouping criteria.
 Example
If a commission of 10% has the validity period 01/01/2004 to 12/31/2004 and a commission of 5% has
the validity period 01/01/2003 to 03/31/2004, the system posts a commission of 5% and an additional
commission of 10% for the first quarter of 2004.
5.1.2.2.5.2.1 Example: Selection of Conditions to Be Posted
This example illustrates which conditions are applied on the basis of the posting data. Key: The rows are color-
coded by condition. You can also see this information from the percentages applied (the last column).
Condition Data

[[Figure]]
When the system calculates an account it creates the following postings.
Condition Postings
[[Figure]]
5.1.2.2.5.3 Condition Categories
The following table contains possible result-independent condition categories and examples of their use.
Condition Category Short Description Examples of Use
Stop Prevents the transfer of postings with ● In retroceded treaties: Stops the
the specified target entry code or the transfer of premiums in non-pro
specified calculation base to the treaty portional business.
or partner involved. ● Treaty calculation rules
Filter Prevents the transfer of all entry codes ● In retroceded treaties: Transfer of
that are not entered directly or indi losses only (and not premiums and
rectly (using a calculation base) in the commissions) in non-proportional
condition. The entry codes entered are business.
used for the specified percentage. ● Treaty calculation rules
Transfer Transfers the contents of a calculation In retroceded treaties: Different calcula

base to an entry code. tion bases are used in ceded and as
sumed business.
Clear Generates offsetting entries for the en ● In mergers and acquisitions: Used
try codes that have been entered in the to write transferred portfolios off to
condition explicitly or using a calcula source objects.
tion base. ● Can be used only in global condi
tions with the category “TXGRP”.
Commission See Result-Independent Commission All commissions that are not result-de
[page 237]. pendent.
Other For more information about reserves, ● Costs

see Reserves [page 290]. ● Reserves
● Taxes
Unearned premiums For more information, see Unearned Carryforward of premium reserves
Premium [page 246].
Portfolio entry For more information, see Portfolio En When a reinsurer enters an existing
try and Withdrawal [page 238]. portfolio.

Condition Category Short Description Examples of Use
Portfolio entry with clearing For more information, see Portfolio En Portfolio entry with the automatic clear
try with Clearing [page 249]. ing of a corresponding portfolio with
drawal. This is available in global condi
tions only.
Portfolio withdrawal For more information, see Portfolio En When a reinsurer withdraws from a
try and Withdrawal [page 238]. portfolio.
The condition categories "Stop", "Filter", and "Transfer" are used to split RI accounts or at the specified time of
use (retrocession, treaty calculation rules, see also the table below); the other categories are used for
calculations.
Criteria for the Individual Categories
Uniqueness for Each Condition Category
The following table provides an overview of the field combinations in the result-independent conditions that
must be unique for each condition category (these are marked with an “x”).
Condition Cat Section Num Share Number Calculation Entry Code Commission Actual/Esti
egory ber Base Deduction mate Indicator
STOP x x x x x
TRAN x x x x x
FIL x x x
COM x x x x x x
PTFE x x x
PTFW x x x
Calculation Times for Each Condition Category
The following table indicates when the different condition categories can be calculated (this is marked with an
“x”).
UEP PTFEC
PTFW
PTFE COM
STOP (un TRAN (portfolio MISC FIL CLRD
(portfolio
earned (portfolio entry (com
(stop) (transfer) with (other) (filter) (clear)
premi entry) with mission)
drawal)
ums) clearing)

ACCT x x x x x x x
(with ev
ery ac
count)
PE x x x x
(end of
treaty
period)
PS x x x x
(start of
treaty
period)
TCR x x x x
(treaty
calcula
tion rule)
PEWDL x
(end of
treaty
period
with
with
drawal)
NONE x x x x x x x x
(none)
RETRO x x x
(retro
cession
calcula
tion)
PRT x
(pro rata)
CAYS x x x x
(start of
calendar
year)

CAYE x x x x
(end of
calendar
year)
STCAN x x x x x
(short-
notice
cancella
tion)
5.1.2.2.5.3.1 Result-Independent Commission
Definition
A commission is a percentage of an amount paid for services rendered; for example, for transferring
reinsurance business. If a commission is result-independent, it means that the amount is not dependent on the
result of the transferred business.
Use
You can enter commission data for a reinsurer section only if there is no sliding scale commission data.
The system automatically calculates and posts the commission directly after it has allocated the amounts to
the reinsurers. The values for the calculation base for these amounts are taken from the relevant processed
account.
In each case, the system recalculates the commission amounts at the end of the year on the basis of all the
accounts for the year. If necessary, it creates an adjustment posting for the difference. The system creates a
closing account at the end of the year only if at least one posting – and therefore one account – exists for the
statistical accounting unit at the end of the year. The statistical accounting unit is determined by the treaty,
treaty number, business type, area, business partner, financial year, and currency.
Structure
A result-independent commission is a result-independent condition [page 231] with the category

“Commission”. You can define a commission as a percentage of a calculation base with minimum and
maximum amounts or as a fixed amount.

5.1.2.2.5.3.2 Portfolio Entry and Withdrawal
Use
When a reinsurer enters a portfolio, it assumes the liability for risks that were already underwritten before its
participation.
If these risks consist of unearned premiums or loss reserves, then these are assumed by the reinsurer.
When a reinsurer withdraws from a portfolio, it must repay the premiums collected but not yet earned. The
reinsurer must also make reserve payments for losses that fall within the coverage period but have not yet been
paid in full.
Since you can define an “account based on the accounting year” separately according to premiums and losses,
you must also define portfolio conditions depending on the partial accounting mode. This means that in a
treaty based on the accounting year you enter premium/loss entry and withdrawal as four separate conditions.
Features
Differentiation According to Year Basis
With the exception of a loss commutation, a premium reserve calculation method can be used only for treaty
parts processed according to accounting year.
Loss commutation is possible for accounting year, occurrence year, and underwriting year.
Portfolio Rule Categories
Portfolio entries and withdrawals are differentiated by loss and premium portfolios.
To simplify the creation of portfolio entries and withdrawals, we recommend you work with condition template
groups. In the template group, you enter the entry code and calculation bases used, as well as the time of
accounting and area of validity of the portfolio posting. For more information about condition templates, see
Result-Independent Condition [page 231].
Note the following:
● The calculation base is the base for calculating portfolio entry or withdrawal. In the case of portfolio
withdrawal, the calculated scope of withdrawal is applied with a minus sign to the posting data for the
current treaty with the entry code for the offset calculation base. This is the same as transferring reserves
to liquid items. A calculation base is therefore used for the offsetting entry because in addition to the
original reserves used to calculate the withdrawal, there are also parallel reserves for calculations using
other accounting principles (GAAP). These calculations using other GAAP are derived from the original
invoice.
● The specified entry code relates to the portfolio posting.
● The portfolio rule accounting time determines when the condition is calculated. In most cases, this is the
start or end of the treaty period.
● The scope determines whether the full reserve is transferred with the withdrawal percentage or whether
only the portion that represents the increase or decrease in the reinsurer’s share from one period to the
next is transferred.

 Note
The condition templates function replaces the portfolio categories defined in Customizing in previous
FS-RI releases.
Area of Validity
You can define portfolio rules for each treaty and treaty year and also, if desired, for the treaty section and the
business partner.
Accounting Time
If withdrawals are arranged on a change of share basis, these are only calculated if the reinsurer reduces its
share for the following year. In the case of complete withdrawal, also known as clean cut, the shares are not
taken into account and instead the full amount of the calculation base is included in the calculation.
In turn, share-related entries are only calculated if the share has increased.
You define the time of accounting in the condition. This indicates when the system calculates the condition.
The system calculates the condition only if the share has changed. In most cases, the time of accounting for
portfolio withdrawal is the end of the treaty period; for portfolio entry, it is the start of the treaty period. The
system then calculates the condition at the required time when calculating accounts.
You can enter a commutation period, after which the first premium reserve calculation method is performed.
In the case of loss portfolios, you can also delay withdrawal by entering a commutation period, after which the
first premium reserve calculation method is performed (see below).
Activities
Defining a Portfolio Entry or Withdrawal
You can perform these steps in a template group or in the treaty itself:
1. Enter the condition category (PTFE or PTFW) and rank.

2. Choose “Enter”. The system opens the relevant fields for this category.
3. Enter the rule. For more information, see the corresponding sections.
4. The system saves these settings and processes the portfolio rules at the specified time.
Example
Examples of Rules for Portfolio Entry and Withdrawal
Commission Target Entry Calculation Offsetting Cal Accounting Scope Percentage

Deduction Code Base culation Base Time
100% Premium port Gross unearned – PS Share change 100

folio entry premium

Commission Target Entry Calculation Offsetting Cal Accounting Scope Percentage
Deduction Code Base culation Base Time
100% Premium port Gross unearned – PS Clean cut 100

folio entry premium
0% Premium port Net unearned – PS Share change 100

folio entry premium
0% Premium port Net unearned – PS Clean cut 100

folio entry premium
100% Premium port Gross unearned Net unearned PE Share change 100
folio withdrawal premium premium
100% Premium port Gross unearned Net unearned PE Clean cut 100
0% Premium port Gross unearned Net unearned PE Share change 100

0% Premium port Gross unearned Net unearned PE Clean cut 100

0% Loss portfolio Loss reserve – PS Share change 100

entry incl. portfolio
0% Loss portfolio Loss reserve – PS Clean cut 100

0% Loss portfolio Annuity reserve – PS Share change 100

0% Loss portfolio Annuity reserve – PS Clean cut 100

0% Loss portfolio Loss reserve Loss reserve PE Share change 100

withdrawal
0% Loss portfolio Loss reserve Loss reserve PE Clean cut 100

withdrawal
0% Loss portfolio Annuity reserve Loss reserve PE Share change 100

withdrawal
0% Loss portfolio Annuity reserve Loss reserve PE Clean cut 100

withdrawal

5.1.2.2.5.3.2.1 Premium Portfolio Withdrawal in Treaty Based
on Accounting Year
Use
When a reinsurer reduces its share in a treaty based on the accounting year at the end of a period (partial
withdrawal) or withdraws completely, this function calculates the premiums that have already been collected
by the reinsurer but will be earned only in following years and must therefore be repaid due to its withdrawal.
The system posts the calculated amount as a portfolio withdrawal. At the same time it reduces the premium
reserve in the same way (offsetting entry). This means that the technical result of the treaty remains the same,
except the transferred unearned premium is a receivable owed by the reinsurer to the cedent.
Prerequisites
You have created the required calculation bases and entry codes in external Customizing for Basic System
under:
● Accounting Entry Code Edit Calculation Bases and Rules

● Accounting Entry Code Edit Entry Code Definitions
Activities
Defining the Withdrawal Rule
You define premium portfolio withdrawal as a result-independent condition with the category “Portfolio
Withdrawal”. The following applies:
● Percentage: The portion of the total unearned premium to be carried forward. In all cases, this is 100%.
● Calculation base: Enter the calculation base containing the unearned premium, for example “Unearned
Premium”. This base is part of the premium base.
● Offset calculation base: The amount accrued is cleared using this calculation base. In most cases, this field
contains the same posting data as in the original calculation base (see above).
● Entry code: The entry code for the portfolio posting.
● Portfolio rule accounting time (usage): Indicates when the condition is calculated (in most cases, at the
end of treaty period).
Account
When it splits an account for the specified treaty, the system:
1. Checks whether the portfolio rule accounting time applies. If it is not, the system terminates processing.
2. Checks whether the business partner’s future share is lower than its past share. If it is not, the system
terminates processing.
3. Uses the premium base containing the share specified by the portfolio category to calculate the amount
that has not yet been earned. This is performed in the calculation base for the unearned premium.

4. Uses the business partner’s past and future share to calculate the portion of the unearned premium that is
still to be earned based on the future involvement of the business partner, and deducts this from the result
in the last step. This is relevant only for partial withdrawal. The deduction is zero for complete withdrawal.
5. Posts the final result with the specified entry code to the current account (when the account is released).
The system creates an open item in favor of the cedent and clears the same amount in the offset
calculation base.
5.1.2.2.5.3.2.2 Loss Portfolio Withdrawal in Treaty Based on

Accounting Year
Use
When a reinsurer reduces its share at the end of a period (partial withdrawal) or withdraws completely, this
function calculates the loss reserves that the reinsurer must set aside for losses that occurred in this period
but have not been processed.
The system uses the percentage calculated from the change of share and portfolio rate for the transfer posting
for the loss reserve in the liquid portfolio withdrawal. The offsetting entry for the loss reserve is the amount
specified as the change of share (100% if clean cut). Any resulting difference immediately affects the net
income.
Prerequisites
under:

Activities
You define loss portfolio withdrawal as a result-independent condition with the category “Portfolio Withdrawal”.
The following applies:
● Percentage: The portion of the total unearned premium to be carried forward. For loss portfolio withdrawal
this may deviate from 100% depending on whether results are good or bad.
● Calculation base: Enter the calculation base containing the loss reserve, for example “Loss Portfolio
Withdrawal”. This base is part of the loss reserve base.
● Offset calculation base: The amount accrued is cleared using this calculation base. In most cases, this is
the same as the original calculation base (see above).

end of treaty period).
Account
2. Checks whether the business partner’s future share is lower than its past share. If it is not, the system
3. Uses the loss reserves containing the percentage specified in the condition to calculate the amount of the
complete loss portfolio withdrawal.
4. Uses, for a share-related withdrawal, the business partner’s past and future share to calculate the portion
of the loss reserve that is still to be paid based on the future involvement of the business partner, and
deducts this from the result in the last step. This is relevant only for partial withdrawal. The deduction is
zero for complete withdrawal.
The system creates an open item in favor of the cedent and clears the same amount in the offset
calculation base.
5.1.2.2.5.3.2.3 Premium Portfolio Entry in Treaty Based on

Accounting Year
Use
When a new reinsurer participates in a treaty based on the accounting year or when the involvement in a period
of an existing participating reinsurer increases, this function calculates the unearned premium received by the
reinsurer for participating in risks for which the premium has already been collected but not yet earned.
Prerequisites
under:

Activities

You define premium portfolio entry as a result-independent condition with the category “Portfolio Entry”. The
following applies:
● Percentage: The portion of the unearned premium from the previous year received by the reinsurer for the
transferred share. In most cases, this is 100%.
● Calculation base: Enter the calculation base containing the portion of the premium to be transferred, for
example “Unearned Premium (Ceded) Without Deduction”. You need to make sure that the calculation
base contains the unadjusted unearned premium. This means that you must not change the calculation
base for the offsetting entry and this must not be influenced by deductions from the previous year.
start of treaty period).
Account
2. Checks, for a share-based portfolio entry, whether the business partner’s share is greater in the current
period than in the previous period. If it is not, the system terminates processing.
3. Uses the unearned premium containing the percentage specified in the condition to calculate the unearned
amount applying to the condition, and then reduces this amount by the commission agreed in the new
treaty year.
4. Uses the business partner’s past and future share to calculate the portion of the unearned premium that is
carried forward based on the past involvement of the business partner, and deducts this from the result in
the last step. This is only relevant when increasing an existing participation because the deduction is zero
for a new portfolio entry.
The system creates an open item in favor of the reinsurer.
5.1.2.2.5.3.2.4 Loss Portfolio Entry in Treaty Based on

Accounting Year
Use
When a new reinsurer participates in a treaty based on the accounting year or when the involvement in a period
of an existing participating reinsurer increases, this function determines the loss reserve carryforwards
received by the reinsurer for participating in risks for which losses exist but have not yet been paid.
Prerequisites
You have created the portfolio category, the calculation bases specified therein, and the entry codes in external
Customizing for Basic System under:

Activities
Defining the Entry Rule
You define loss portfolio entry as a result-independent condition with the category “Portfolio Entry”. The
following applies:
● Percentage: The portion of the loss reserve from the previous year received by the reinsurer for the
transferred share. In most cases, this is 100%.
● Calculation base: Enter the calculation base that contains the part of the loss reserve to be transferred, for
example “Outgoing Loss Reserves”. You must make sure that the calculation base, the contents of which
are taken from the previous year, are not falsified by offsetting entries.
start of treaty period).
Account
2. Checks whether the business partner’s future share is greater than its past share. If it is not, the system
3. Uses the loss reserves containing the percentage specified in the condition to calculate the modified loss
reserve carryforward applying to the condition.
4. Uses the business partner’s past and future share to calculate the portion of the loss reserve carryforward
that is brought forward based on the past involvement of the business partner, and deducts this from the
result in the last step. This is only relevant when increasing an existing participation because the deduction
is zero for a new portfolio entry.
The system creates an open item in favor of the reinsurer.
5.1.2.2.5.3.2.5 Delayed Portfolio Withdrawal
Use
The account uses this function if you have entered a portfolio withdrawal with a commutation period in the
treaty. This is also known as a loss commutation.

Prerequisites
● The treaty for which an account is created contains a result-independent condition with the category
"Portfolio Withdrawal" clean cut to the end of treaty period, and a commutation period.
● You have defined an entry code for portfolio commutation in Customizing. You must set the Cash Balance
checkbox for this entry code. The entry code type corresponds to that of the entry code contained in the
calculation base. You edit the entry code in Customizing for Basic System under Accounting Entry
Code Edit Entry Code Definitions .
Features
As soon as the gap between the occurrence and accounting year is the same as that entered as the
commutation period and the end of the treaty period has been reached, the system posts the existing loss
reserves, and those defined using the calculation base, as a portfolio withdrawal. This means that the loss
reserves for the commuted treaty year are zero for all accounting principles.
If this gap is greater, the system stops all entry codes contained in the calculation base for this share and
transfers the posting to a commuted entry code. This must be specified in Customizing for each entry code
that may be commuted. Commuted entry codes are usually provided for information purposes only.
To make proper use of this function, you must create a commutation rule for the loss reserves with the required
commutation period. Since loss payments reported at the time of commutation may be transferred once, and
once only, you must also create a commutation rule for loss payments with the above commutation period plus
one year. This means that loss payments from commuted business are not constantly passed on to the
reinsurer.
5.1.2.2.5.3.3 Unearned Premium
Use
The portion of the premium that has been collected in a financial year; the entire premium is earned after the
end of the closing periods.
Unearned premiums are amounts already received that are assigned to the income statement for future
periods.
Features
You enter an unearned premium in a treaty as a result-independent condition. When you create, and calculate,
an account for this treaty, the system determines the amount to be carried forward according to the specified

calculation method and creates the corresponding posting. The following methods are calculated by the
Calculate Unearned Premiums background job:
● Pattern-Supported Accruals and Deferrals

● Accruals/Deferrals Up To Period End
Calculation Methods for Unearned Premiums
You can use various methods to distribute the unearned premium between the current year and the following
year.
Pattern-Supported Accruals and Deferrals
This method can be used only through global conditions [page 251] with the category “LINK”.
The unearned premiums are calculated based on the development patterns entered in Customizing. This
means that linear curves and curves can be defined.
Statistical unearned premiums are always calculated based on the end date of the accounting period of the
underlying posting.
Unearned premiums on the balance sheet are always calculated based on the FI posting date of the account
that contains the underlying posting. For more information, see Transfer Exchange Rate [page 144] and the
Calculate Unearned Premiums background job.
Accruals/Deferrals Up To Period End
This method can be used only through global conditions [page 251] with the category “LINK”.
Statistical unearned premiums are always calculated based on the end date of the accounting period of the
underlying posting.
Unearned premiums on the balance sheet are always calculated based on the FI posting date of the account
that contains the underlying posting.
In both cases, the system considers the days per year rule [page 23] of the business partner: In the case of
statistical unearned premiums, the days per year rule of the cedent applies and in the case of balance-sheet
unearned premiums, the days per year rule of the reinsurer applies. For more information, see Transfer
Exchange Rate [page 144] and the Calculate Unearned Premiums background job.
Flat-Rate Method
This method is based on the assumption that the process is spread evenly over the financial year. A fixed
percentage of the premium is carried forward accordingly.
Pro Rata Temporis Method
The unearned premium is determined individually for each policy or treaty. The contribution margin for the
following period is set in relation to the entire policy duration. This method is applied when you use Risk
Manager.
Calculation formula: unearned premium = premium x number of days (key date, end of revenue period) /
number of days (revenue period)
Amounts can be accrued or deferred on the basis of a 360-, 365- or 366-day model, depending on the entry in
Customizing.
Fractional Value Method

This method is an approximation of the pro rata temporis method. The unearned premium varies depending on
the time segment of the outward year. The FS-RI system supports the fractional value methods: 1/6th, 1/8th,
1/12th, and 1/24th.
To be able to use fractional value methods, you must use the accounting frequency assumed by the method;
for example quarterly in the case of the 1/8th method.
It really only makes sense to use fractional value methods for annual closing periods; you cannot provide
correct carryforwards for mid-year financial statements.
Unearned Premium for 1/6th Method
Four-Month Period Unearned Premium Earned Premium
01/01 – 04/30 5/6 1/6
05/01 – 08/31 3/6 3/6
09/01 – 12/31 1/6 5/6
Quarter Unearned Premium Earned Premium
01/01 – 03/31 7/8 1/8
04/01 – 06/30 5/8 3/8
07/01 – 09/30 3/8 5/8
10/01 – 12/31 1/8 7/8
Two-Month Period Unearned Premium Earned Premium
01/01 – 02/28 / 02/29 11/12 1/12
03/01 – 04/30 9/12 3/12
05/01 – 06/30 7/12 5/12
07/01 – 08/31 5/12 7/12
09/01 – 10/30 3/12 9/12
11/01 – 12/31 1/12 11/12

Month Unearned Premium Earned Premium
January 23/24 1/24
February 21/24 3/24
March 19/24 5/24
April 17/24 7/24
May 15/24 9/24
June 13/24 11/24
July 11/24 13/24
August 9/24 15/24
September 7/24 17/24
October 5/24 19/24
November 3/24 21/24
December 1/24 23/24
5.1.2.2.5.3.3.1 Portfolio Entry with Clearing
Use
The condition category “Portfolio Entry with Clearing” (PTFEC) is available only in global conditions [page 251]
with the category STD (standard) and can exist only in conjunction with a condition with the category “Portfolio
Withdrawal” (PTFW).
You can use the pairing of PTFW and PTFEC to post unearned premiums in occurrence year treaties as portfolio
withdrawals in the previous treaty period (previous occurrence year) and as portfolio entries in the new treaty
period (new occurrence year).
Features
The condition category “PTF Entry with Clearing” allows for conditions with direct reference to a portfolio
withdrawal condition. You do not have to create this reference manually using entry codes and calculation
bases. Rather, it is created using the reference rank for the PTFEC condition, which must contain the rank value
of a PTFW condition. The calculation base is always comprised of 100% of the posting data created by the
assigned PTFW condition. The PTFEC condition contains only the date and the entry code for the offsetting
entry for PTFW posting data.

The portfolio withdrawal is posted as a liquid item for the corresponding entry code. If you trigger the portfolio
entry posting using the PTFEC condition, the system automatically clears this open item in FS-CD.
The portfolio entry is only posted if a treaty period exists that lies after the period of the portfolio withdrawal.
Activities
1. Create a PTFW condition

Before you can use a PTFEC condition, you have to create a PTFW condition as the reference point for the
PTFEC condition. For the premium amounts to be carried forward, this PTFW condition must post a
portfolio withdrawal at the end of the period to a liquid entry code.
2. Create a PTFEC condition
You then create a PTFEC condition for this PTFW condition. This PTFEC condition re-posts the cleared
amounts at the start of the following period. The PTFEC condition must be one rank higher than that of the
PTFW condition and its reference rank must refer to the rank of the PTFW condition. In the PTFEC
condition you must also specify which entry code is to be used to post the portfolio entries.
3. Run the "Calculate Global Conditions" background job
When the background job calculates the global condition using the pairing of PTFW and PTFEC it checks
which premium amounts are to be carried forward to the next period. It generates in this period the
corresponding withdrawal postings for the period specified in the PTFW condition. An open item with a
clearing lock is generated in FS-CD.
 Note
The system processes only global conditions with the category STD.
For treaties for which the next period has already been created, the background job generates in the
same run the portfolio entry postings for the next period. The open item is cleared in FS-CD at the
same time.
For treaties for which a next period has not yet been created, the item remains open in FS-CD. As soon
as the following period has been created and the background job has been started again, the system
posts the portfolio entry and clears the corresponding item in FS-CD.
Example
For an example, see Unearned Premiums in Occurrence Year Business with Global Conditions [page 253].

5.1.2.2.5.4 Global Condition
Definition
A global condition bundles any number of result-independent conditions centrally and across treaties. Global
conditions can be used in different functions. A distinction is made between the following categories:
● STD – standard
● TXGRP – transfer group
● TCR – treaty calculation rule
● LINK – link in result-independent conditions in treaty
The conditions in a global condition with the category STD apply to all the treaties in the FS-RI client that fulfill
the criteria defined in the global condition. These conditions apply to only those treaty sections in these
treaties in which the “Apply Global Conditions” checkbox has been selected. You use the “Calculate Global
Conditions” background job to calculate this category. You can use the following condition categories in a
global condition with the category STD:
● UEP – unearned premiums

● PTFE – portfolio entry
● PTFW – portfolio withdrawal
● PTFEC – portfolio entry with clearing
● COM – commission
● OTHER – other
The validity of a global condition with the category STD can be restricted using the following selection criteria.
These criteria are entered in the header data of the global condition:
● Treaty Category
● Nature of Treaty
● Treaty Type
● Start of Treaty Period
● Premium Mode
● Loss Mode
● Class of Business
● Area
● Business Type
● Line of Business
You can use a global condition with the category TCR in the # and = ranks of a treaty calculation rule. These
global conditions are included when the system executes the treaty calculation as part of the “Calculate”
function.
 Note
Result-independent conditions with the usage TCR in the target treaties are overridden by the global
conditions of the treaty calculation rules.
You can use the following condition categories in a global condition with the category TCR:
● STOP – stop

● TRAN – transfer
● FIL – filter
Global conditions with the category TXGRP are used in the transfer groups. Here they specify which posting
data is processed during a portfolio transfer. Selection periods are available in the global conditions.
The following gives you an overview of the permitted combinations for TXGRP of target entry code, calculation
base, and selection period.
Combinations for TXGRP Incremental Year to Date Inception to Date
Non-reserve entry code Permitted Excluded by a check Permitted
Reserve entry code Permitted Permitted Excluded by a check
For more information, see "Mergers and Acquisitions: Procedure".
Global conditions with the category LINK can be entered on the Result-Independent Conditions tab page in the
treaty. This means that you can create a link to the conditions stored centrally without physically saving the
global condition data in the treaty.
As a result, global conditions with the category LINK are a direct alternative to the result-independent condition
groups. The system always evaluates this link when you execute the “Calculate” function for an account. For
example, this can be when you calculate data, check conditions, use the Adjust Periods background job, or use
the Calculate function within background jobs.
You can also calculate unearned premiums [page 246] for specific periods using global conditions with the
category LINK.
Use
You can use global conditions to globally define, and if necessary change, conditions that are not specific to a
treaty but to a business area. Examples of this include unearned premiums or certain taxes that are due for all
the treaties in a specific group in a region.
Structure
Transactions
You use Edit Global Conditions (transaction /MSG/R_V_GKV02) to edit global conditions.
You use Display Global Conditions (transaction /MSG/R_V_GKV03) to display global conditions.
Identification
Every global condition is uniquely identified by the global condition number and can also have a user-defined
name as well as a company code.
Area of Application
The Active checkbox determines whether the global condition is active.

Global conditions with the category STD do not apply to treaty sections in which the Apply Global Conditions
checkbox has not been selected at section level.
The Apply Global Conditions checkbox is not required at section level for the categories TCR, TXGRP and LINK.
Example
● Unearned Premiums in Occurrence Year Business with Global Conditions [page 253]
● Fire Department Charges with Global Conditions [page 255]
5.1.2.2.5.4.1 Unearned Premiums in Occurrence Year

Business with Global Conditions
Use
In many of your treaties a premium payment has been agreed that is not paid for each financial year but at the
start of a period that lasts several years or at the start of a treaty year that is not the same as the financial year.
To create the financial statements correctly, you have to post unearned premiums for these treaties.
So that you do not have to enter the unearned premiums as a condition in every individual treaty, you use a
global condition [page 251].
This example demonstrates the functions of a global condition for unearned premiums in occurrence year
business.
Prerequisites
You have created the following entry codes and calculation base:
● Entry code 1000: premium

● Entry code 11: premium portfolio entry
● Entry code 12: premium portfolio withdrawal
● Calculation base 10: posted premium
Activities
Create Global Conditions for Occurrence Year Treaties
Use the transaction /msg/r_v_gkv02 to create a global condition with the following data.
Criteria for Treaty Selection

● Premium mode: occurrence year
Condition 1 (PTF withdrawal)
● Category: PTF withdrawal

● Rank: 1
● Valid from: January 1, 2001
● Valid to: December 31, 2099
● Entry code: 12 (premium portfolio withdrawal)
● Actual/estimate indicator: FINAL
● Method: PERC
● Percentage: 100
● Clearing lock: A: posting/clearing
● Calculation base: 10 (posted premium)
● Calculable: yes
● Offset calculation base: 10 (posted premium)
● Usage: end of period
● Module: Basic System
● Scope: clean cut
Condition 2 (PTF entry)
● Category: PTF entry with clearing

● Rank: 2
● Reference rank: 1
● Valid from: January 1, 2001
● Valid to: December 31, 2099
● Entry code: 11 (premium portfolio entry)
● Actual/estimate indicator: FINAL
● Method: PERC
● Calculable: yes
● Usage: start of period
● Module: Basic System
● Scope: clean cut
Select Treaties
Set the Apply Global Conditions checkbox in all the relevant treaty sections at treaty section level.
Calculate and Post Unearned Premiums
Run the Calculate Global Conditions [page 537] background job to calculate the global condition created above
at the transition point between the periods. To do this, enter the variant for the background job as follows:
● Key date from: January 1, 2008 to January 2, 2009

● Global condition to be used: the global condition created
● Scope of processing: release
Result
The background job generates two accounts for each affected treaty with the following postings (where the
amount to be transferred is assumed to be EUR 1,000).

Account 1
Accounting period 2008/Q4
● A posting of EUR 1,000 to entry code 12 (premium portfolio withdrawal)

● A posting of EUR -1,000 to entry code 1000 (premium)
Account 2
Accounting period 2009/Q1
● A posting of EUR 1,000 to entry code 11 (premium portfolio entry)

● A posting of EUR -1,000 to entry code 12 (premium portfolio withdrawal)
5.1.2.2.5.4.2 Fire Department Charges with Global Conditions
Use
In Germany, fire department charges must be collected for every premium paid for the classes of business
"fire", "buildings", and "householder's comprehensive insurance". Therefore, we recommend you define these
charges in corresponding global conditions [page 251] and use these conditions to create the relevant
accounts. In this example, a global condition is created for the class of business "fire".
The fire department charges are due one month after the end of the calendar quarter and make up 8% of the
fire insurance policy.
Activities
Create a Global Condition Template for the Class of Business "Fire"
Under Edit Global Conditions (transaction /MSG/R_V_GKV02), create a global condition with the following data.
Criteria for Treaty Selection
● Treaty category: ceded reinsurance
Criteria for Posting Selection
● Class of business: fire

● Area: Germany
Details
Create a condition with the following data:
● Category: other
● Rank: 1
● Entry code: your entry code for fire department charges, such as 2070
● Percentage: 8
● Calculation base: posted premium

● Usage: with every account
Select Treaties
Select the Apply Global Conditions checkbox in all the relevant treaty sections at treaty section level.
Calculate and Post Fire Department Charges
In the Calculate Global Conditions [page 537] background job, schedule the quarterly calculation of the global
condition created above (in each case at the start of the next quarter). To do this, enter the variant for the
background job as follows:
● FI posting date: the last day of the month after the end of the quarter
● Key date from: the first day of the quarter
● Key date to: the last day of the quarter
● Global condition: the ID of the global condition in this example
Result
The system calculates and automatically posts the fire department charges due to the treaties defined by the
selection criteria within the specified time.
5.1.2.2.5.5 Copying Result-Independent Conditions
1. On the Result-Independent Conditions tab page at treaty period level, choose the condition you want to
copy.
2. Choose the pushbutton.

3. Enter the required data in the dialog box.
4. The system copies the condition.
 Note
The system copies all input-enabled fields into the target condition. You cannot copy from an assumed
portfolio treaty to a ceded portfolio treaty, and vice versa. You also cannot copy to or from an assumed and
ceded portfolio treaty. The portfolio category is predefined in Customizing. This field is otherwise not used
and is locked.
5.1.2.2.6 Conditions for Life Business
Use
These conditions are an extension of the result-independent conditions. As such, they are independent of the
insurance-related outcome of a reinsurance treaty (high or low loss ratio or premium income). Condition
Manager is available only in proportional treaties with the treaty class “Life”.
The conditions are split into different condition types and comprise the condition itself (such as an amount,
formula, or factor), the condition base (condition type and formula), the relevant area of application (set of
attributes, section, partner involved), and the validity area (validity and new business period).

You can indicate that conditions are for information purposes only (“informative”), which means that they
cannot be used to create accounts. The system performs fewer validation checks for “informative” conditions.
You cannot change non-informative conditions that have already been used in the account or conditions in
generations where posting is allowed (Cond. Block checkbox is set).
Condition Types
You define the available condition types in Customizing and assign each type to a condition class, treaty class,
and module.
You can enter the condition type at condition level and in the condition base. In Customizing you can specify
whether a condition type is entered in the condition and/or condition base.
For each condition type used in the condition, you also specify in Customizing which of the fields in the areas of
application and validity are required entries, optional entries, or deactivated. Similarly, for each condition type
you also specify whether the input fields for the condition and condition base are required entry fields, optional
entry fields, or deactivated. (Exception: “Informative” conditions do not have required entry fields.)
Condition
You define the actual condition using a fixed amount (currency), factor, or a formula imported from
msg.ProductManager. Note that you can only use one of these options.
Condition Base
A condition can be based on a condition base that either refers to a different condition type or consists of a
formula from msg.ProductManager.
Formulas from Product Manager (msg.PM)
In msg.PM every formula that is available in Condition Manager is stored internally as a product. The available
formulas (products) are defined in msg.ProductManager by the product model and the current product
collection version.
The formulas that can be used with a condition also depend on the selected condition type (each condition
product in msg.ProductManager has a corresponding attribute).
If a condition formula is selected, only certain formulas are available in the condition base. (These condition
base products are defined in msg.ProductManager by a relationship to the condition product.) If a condition
formula is not selected, you can choose all the formulas in the condition base.
After you have selected a formula, you can enter additional formula parameters if required. The number and
category of the formula parameters depend on the definition of the formula in msg.ProductManager. You can
enter and save a value for each formula parameter. As soon as you have saved the parameter values, the
formula is locked and cannot be changed. This means that you have to explicitly remove the existing formula
before you can choose a new one.
Area of Validity
The condition is valid for new policies within the new business period and only for the specified validity period.
This means that you can define various conditions for different periods of time (to reflect changes in the
insurance tax from a certain date, for example).
The conditions for a certain policy must be unique at any given point in time. In other words, conditions of the
same condition type must not overlap in their area of application or validity area. (Exception: “Informative”
conditions can overlap with other conditions because they are not used for processing.)
If you enter a filter date, you can display all the conditions with validity periods that include this date.

Area of Application
You can assign conditions to a specific section and/or partner involved in the generation. The conditions are
then restricted to this object.
Conditions that are not explicitly assigned to a section or partner involved automatically apply to all the
sections/partners involved in the current generation.
Set of Attributes
You use a “set of attributes” to define the area of application for a condition.
The set of attributes overcomes the problem of rigidly classifying attributes for each section (treaty type, class
of business, area, business type, and currency). Instead, you can now use freely-definable, dynamic classifying
attributes, which cover the different logical components of a policy.
A set of attributes comprises a series of attributes (permanently stored or imported from

msg.ProductManager) with linked conditions. The attributes are assigned a specific value type (“character
string/value set”, “amount”, “number”, “percentage”, or “date”) in Customizing. This value type determines
the fields that are active and the procedure for entering the attribute. In the case of “character string and value
set” attributes, you can store input help and a restricted value set. In this case, you can only choose from these
values. For example, you can define an attribute called Gender that can only have the values “male”, “female”,
or “unknown”.
With all the other attribute types, you can enter any value. For example, the attribute called Entry Age allows
you to enter any integer. The Sum Insured attribute can be any fixed value.
The criteria for each attribute (row) can include one or two comparison operators, in the form “attribute >
value 1” or “attribute > value 1 < value 2” (other operators can be used instead of “>”). The operators in a row
are always logically linked with “AND”. The various rows in a set of attributes are also logically linked with “AND”
(with the exception of rows in the same attribute, which are linked with “OR”).
 Example
Age > 29 < 61
AND link (Age attribute is restricted by two operators in one row): Is true if the age is between 30 AND 60
(greater than 29 AND less than 61).
Age < 61
Gender = M
AND link (Age attribute is restricted by a further row with a “gender” attribute): Is true if the age is below 60
AND the gender is male.
Age > 39 < 61
Age > 1 < 22
OR link (Age attribute is used in two rows): Is true if the age is either between 40 AND 60 OR between 2
AND 21.
When you assign a set of attributes to a condition, you use the criteria for the attribute to restrict the area of
application.
The sets of attributes defined in the conditions are processed at a later point in time in SAP FS-RI Risk Manager
(Life).

Set Name
A set of attributes is defined once and exists throughout the entire treaty. It can also be assigned to other
conditions for a generation contained in the treaty. You save a set of attributes under a unique set name in the
treaty (the system automatically assigns an internal set number).
You can define several attributes in Customizing for each condition class (and company code if necessary).
These must then be entered in the set of attributes for each condition of this class, or are prohibited in the set
of attributes.
You can change the set name of a set of attributes at any time (the internal number stays the same).
You can also copy an existing set of attributes with all the attributes it contains. To do so, you have to enter a
new name for the “target” set of attributes.
When you delete a condition, the assigned set of attributes is retained. You can only delete a set of attributes if
it is no longer used by any condition (in the generations of the current treaty). If a certain set of attributes is
assigned to a condition that was already used in the account, you cannot change this set of attributes. If you
change the attributes, you must save them under a new set of attributes.
However, if a set of attributes is used by several conditions that have not been used in an account or a
generation where postings are allowed, you can still change the set of attributes. Note that the changes you
make apply to each of these conditions.
Features
Conditions
● Create: You can create a new condition.

● Change: You can change existing conditions as long as they have not been used in an account (or in a
generation where postings are allowed).
● Delete: You can delete existing conditions as long as they have not been used in a posting (or in a
generation where postings are allowed).
● Filter: You can filter conditions that are valid on a specific date.
● Copy: You can copy an existing condition to a new condition. When you do so, the system copies the
condition values, condition base, and validity period. The Condition Block checkbox, the For Information
checkbox, the Note field, and the set of attributes are not copied.
Set of Attributes
● Create: You can create a new set of attributes and link it to a condition.
● Copy: You can copy an existing set of attributes to a new set. When you do so, the system also copies all
the attributes, operators, and values to the new set of attributes.
● Rename: You can assign a new name that is unique within the treaty to an existing set of attributes at any
time.
● Change: You can change the attributes, operators, and values of an existing set of attributes. If the set of
attributes is already assigned to other conditions that have been posted, you must save the changes under
a new name.
● Default: You can store a “template set of attributes” for a condition class (for each company code) in
Customizing. When you create a condition, the system fills the Set of Attributes tab page with the attributes
from this template.

● Delete: You can only delete a set of attributes if it is not used by a condition (in the entire treaty).
5.1.2.2.7 Funds
Definition
A fund is a sum of money set aside to ensure payment of premiums or losses, either with the creditor itself or
with a trust company.
In the FS-RI system, you can define different types of security deposits in the form of cash or securities. In the
case of cash, the system supports the calculation of funds retained and released, as well as interest and tax on
interest, at defined points in time. You cannot calculate securities using the FS-RI system but you can enter
these for information purposes.
Use
If you have agreed with your business partner to retain a fund, you create this in the treaty at partners involved
level. You can create more than one fund; for example, for each business partner in the treaty.
When you create a fund, you also specify how the system calculates the funds retained and release of funds
[page 261] and when it posts amounts.
Structure
To work with funds, you must maintain the following settings in Customizing:
● FS-RI Reinsurance Basic System Treaty Funds Edit Fund Collection Method
● FS-RI Reinsurance Basic System Treaty Funds Edit Retention Methods
FS-RI Reinsurance Basic System Treaty Funds Edit Release Methods
● FS-RI Reinsurance Basic System Treaty Funds Edit Fund Types
● FS-RI Reinsurance Basic System Accounting Entry Code Edit Entry Code Definitions (here you
can define entry codes for funds retained and released)
You can find information about funds in the following places in the treaty:
● The Funds tab page at period level provides an overview of the funds for all partners involved/shares in the
current period. If you double-click an entry on this tab page the system branches to the detail view for the
fund, where it is possible to make changes.
● The Funds tab page at partners involved level provides an overview of all the existing funds for each partner
involved. If you double-click an entry on this tab page the system branches to the detail view for the fund,
where it is possible to make changes. If you want to view all the funds held, select Basic System
Account Display Total Funds Held from the initial menu.

Integration
The system calculates the funds retained and released, together with the result-independent conditions, in the
accounts or when recalculating conditions.
5.1.2.2.7.1 Funds Retained and Release of Funds
Use
These functions are used as part of the accounting process to post an amount to the fund or write off this
amount. In the treaty under funds data, you enter the accounts in which funds are retained or released and how
the amount retained and released is calculated.
Integration
If several funds and result-independent conditions exist, the system processes these in the account in the
sequence of their rank numbers. If a result-independent condition and a fund have the same rank number, the
system internally assigns to the fund the next rank number not yet allocated to a result-independent condition.
In the account for a fund, the system always calculates the funds retained and then the release of funds.
The system processes result-dependent conditions separately.
 Example
Internal Processing Rank Result-Independent Condition/Fund Rank Number
1 Result-independent condition 1
2 Fund 1
3 Result-independent condition 2
4 Fund 3
Prerequisites
● You have entered the calculable fund, for which a retained amount is to be posted, in the treaty.
● The account in which you want to enter the funds retained or the release a fund matches the date specified
by the funds retained or release method.
● You have made all the necessary settings for funds [page 260] in Customizing.

Features
When you create a fund-related account, the system always generates accounts for all the funds for a treaty
and reinsurer. For this reason, you should note the following:
● Select retention and release methods that make a useful combination. As a rule, the retention and release
of funds should take place at the same time.
● The system releases an account even if you have not entered a calculation base that would trigger
retention. This means that for certain release methods after the system has processed the account, the
total funds held is equal to zero. To avoid this problem, select retention and release methods that ensure
entries are made in the corresponding account (for example in the case of a premium deposit) at the
portfolio rule accounting times at which the premium is also paid. You can also select a release method
that refers to a previous status.
Activities
The system performs the following fund-related activities with every account:
● It determines whether funds are retained

The retention type selected in the funds data in the treaty determines when the funds are retained. This
can be with every account, at year end, or when the final account is created on cancellation of the treaty.
● It posts the funds retained to the entry code defined in Customizing
The system calculates the funds retained as a share of a calculation base, based on the data entered in the
funds data in the treaty. The retention type determines the time to which the basic values for the
calculation base refer.
● It determines whether funds are released
The release method selected in the funds data in the treaty determines when the funds are released. This
can be with every account, with the next account, or at year end.
● It posts the amount released to the entry code defined in Customizing
The system calculates the amount released either from the total funds held or from one or more funds
retained, based on the release method.
● It posts the interest on funds and tax on this interest to the entry codes defined in Customizing
If you enter a percentage for the interest on funds in the treaty under funds data, the system multiplies the
amount released by this percentage and posts the result. If you enter a tax rate for the tax on this interest
in the treaty under funds data, the system multiplies the interest amount by this percentage and posts the
result.
 Note
Note that the system does not calculate the interest on funds based on the retention period of the
money in the fund. If you have agreed an annual rate of interest with your business partner for example,
but calculate funds retained and the release of funds quarterly, you must adjust the interest entered in
the treaty accordingly.

5.1.2.2.7.1.1 Currency Handling for Funds Retained and
Release of Funds
Use
The exchange rate between the original and account currency usually fluctuates between the time of fund
retention and the time of fund release. To clear this amount, when a fund is released the system calculates the
difference between these currencies. The system then posts this difference amount to a separate entry code
defined in Customizing.
Prerequisites
The system can consider exchange rate fluctuations only if you have released the fund using:
● The Calculate function in the accounting function

● The Period-End Closing background job
If you create the postings for the release of funds manually, the system cannot consider exchange rate
fluctuations.
Before you post the clearing amount, you must have defined a corresponding entry code in Customizing for
Basic System under Accounting Entry Code Edit Entry Code Definitions .
Example
Amounts are retained in a fund in euros at a given dollar rate. At the end of the year, the funds are released in
euros.
Amounts Retained
Retention 1 EUR 1000 USD 980 Exchange rate: 0.98
Total retention in EUR: 3000
Total retention in USD: 2940
Release
Released at year end EUR 3000 USD 2880 Exchange rate: 0.96

The currency conversion difference between the total amount retained and released in USD is USD 60 (2,940 –
2,880).
The system posts this amount as a separate entry for exchange rate fluctuations.
5.1.2.2.8 Exposure Data
Exposure data provides information about the quality of a risk. You can enter this information at treaty period
level on the tab page of the same name. In addition to exposure data, you can also create value types and value
type groups.
In the FS-RI system, exposure data is stored for information purposes only and has no effect on system
functions.
5.1.2.2.9 Indexation
Use
You use an indexation clause in the treaty for the partners involved to ensure the debit resulting from a rise in
the value of losses in non-proportional reinsurance treaties running for several years is distributed fairly
between primary insurer and reinsurer. The relevant amounts are then adjusted according to this clause. The
system performs this adjustment automatically if you enter the relevant data on the NP Liability tab page at
section level in the treaty.
Prerequisites
Before you work with indexed amounts, you must have:
● Defined the index series to be used in the master data

● Entered the values for the index indicator in Customizing for FS-RI Reinsurance under Basic System
Treaty NP Data Edit Index Indicator .
Features
Indexation Methods
● Joint indexation:
In this indexation method, the following formula is always used to adjust an LUD pair: Σ payments or
reserves / Σ payments and reserves indexed

● Separate indexation:
In this indexation method, the formula used to adjust LUD pairs depends on whether these are for
payments or reserves.
○ LUDs for payments: Σ payments / Σ payments indexed
○ LUDs for reserves: Σ reserves / Σ payments and reserves indexed
Inflation Clauses
The actual index value used for indexation is calculated as follows:
● Standard inflation clause:

Index factor for base year / index factor for calculation year
● Severe inflation clause:
(1 + margin) x index factor for base year / index factor for calculation year
Activities
When you create a treaty in the FS-RI system, you specify the procedure agreed on in the indexation clause in
the treaty document on the NP Liability tab page under Index Data. You can view the index definition directly
from the treaty by choosing Environment Index Definition .
If a period-dependent amount is to be calculated within the treaty:
● The system compares the percentage calculated using the index series with the percentage specified as
the margin. If the percentage specified as the margin is greater, indexation is not performed.
● If indexation is performed for the amount, the system adjusts the value according to the above formulas.
5.1.2.3 Treaty Section
Definition
Sections subdivide the structure of a treaty. Each section is uniquely identified by a class of business, area, line
of business, area covered, business type, treaty type, and currency. Each treaty must have at least one section.
Use
You can use as many sections as you want to subdivide the scope of your treaty. You can also create several
classes of business, currencies, and so on, in a section. If you have agreed various conditions for different parts
of the treaty (profit commissions of different amounts for fire and liability business, for example), you must
create a section for each condition.

Structure
To go to section level, double-click a section on the Section tab page at treaty header or period level. You can
create a section only at period level.
Each section is divided into the section header and the section details.
Section Header
The section header contains general information about the section, for example, the validity period, section
number, and main structural characteristics.
Structural Characteristics
The structural characteristics saved in the section describe the type and scope of the reinsurance business. A
section can also contain multiple values for a certain characteristic, in which case the value specified in the
Structure Elements section on the Section tab page is always regarded as the main characteristic. For more
information about multiple characteristic values, see Structural Characteristics and Splits [page 277]. The
following are regarded as structural characteristics:
● Treaty type
● Area
● Business type
● Currency
● Class of business
● Line of business (if the appropriate settings have been made in Customizing)
Treaty Figures and Conditions
You enter the treaty data, such as layers or shares, conditions and clauses, on the different tab pages for the
section and in some of the detail views below these. For more information, see the corresponding sections.
Integration
Section in Treaty Period
A treaty period cannot contain more than one section with the same header data. To ensure this, the system
checks the following:
● Counter for treaty type

● Treaty type
● Business type
● Area
● Line of business (if the appropriate settings have been made in Customizing)
A section can cover one treaty period only, but you can create a copy of a section in another period of the
treaty.
Underlying Sections
You can create several sections within a treaty to describe different layers.

5.1.2.3.1 Working with Treaty Sections
The following functions are available for editing treaty sections.
Create section At period level on the Sections tab page,
choose the pushbutton or choose
Edit Create Entry .
Create section with the same header (in At period level on the Sections tab page, The following parameters of the new
another period) section are identical to the existing sec
choose the pushbutton or choose
tion with the same header:
Edit Create Entry .
● Treaty type
Select as the section number the num
ber of the section whose header data
● Area
you want to copy.
● Business type
● Layer
● Line of business (if available and if
the appropriate Customizing set
tings are made)
● Main/original fields
● Premium and loss modes
Edit section Switch to the section header and dou If a section exists in more than one pe
ble-click the section or select the sec riod, the system opens the section in
the most recent period that has a sta
tion and choose .
tus that “allows posting” and is “not
canceled”.
If no such period exists, the system se

lects the most recent period that has a
status that “allows posting” and is “can
celed”.
If no such period exists, the system se

lects the most recent period.
If you want to edit the section in an

other period, select this in the header
data.
Copy section See Copying Treaty Sections [page

303].

Delete section Select one or more sections in the sec The following conditions apply when
you delete a section:
tion header and choose .
● The section is not a retrocession
The system deletes the section header
section, is not assigned to a com
when you delete the last section be
pensation rule, is not an XL fca
longing to this header.
section and is not assigned to a
loss
● If the section to be deleted exists in
one period only, you can delete it
only if it is not used in an account
or in treaty calculation rules.
5.1.2.3.2 Installment Schedule
Definition
You enter the number, date, and amount of advance premiums in the installment schedule.
Use
In non-proportional business, premiums are usually paid during the period and not with the final account at the
end of the period.
Structure
You find the data for the installment schedule on two levels: on the Installments tab page at section level and on
the level below.
Integration
If the “Premium Mode” is set to “Occurrence Year”, the due dates must be within the period. If not, the dates
can extend beyond the end of the period.
Installments can be due at any time and can each constitute a freely-definable share of the advance premium
for the particular currency.
In the Share in % field, you enter the share of an installment of the total advance premium for each currency.

The installment percentages refer to the amount on the overview page for the installment schedule.
The sum of the shares must not be greater than 100%.
You can post the premium automatically (using a background job). The system then enters the account date.
Possible Actions
● Create
You can create an installment schedule, either manually or automatically, by choosing the Generate
Installment Schedule [page 269] pushbutton. You can also create an installment schedule automatically by
choosing CTRL + SHIFT + F11 or Goto Generate Installment Schedule .
● Change
You can change an installment schedule.
● Delete
You can delete an installment schedule.
Overview of the Installment Schedule
You find an overview of the installment schedule at section level in non-proportional treaties.
You can create installment schedules in more than one currency. This enables you to pay some of the
installments in EUR and others in USD, for example. You enter the installment amount and the corresponding
currency on the Installment Schedule tab page. You can use only currencies that have been entered as original
currencies in the currency split table.
This tab page also displays the number of installments in the respective currency.
The system calculates the advance premium on the NP Premium tab page using the sum of the amounts
entered on the Installment Schedule tab page.
You can branch to the actual installment schedule by choosing an entry on the Installment Schedule tab page.
Here you enter the number, amount, and due date of the installments for the advance premium.
Possible Actions
● Add
● Delete
You can select and then delete one or more installment schedules.
● Goto
You can branch to the installment schedule for a specific currency.
Generate Installment Schedule Automatically
You can create an installment schedule automatically by choosing the Generate Installment Schedule
pushbutton. When you choose this pushbutton, the Generate Installment Schedule dialog box appears. In this
dialog box, you can enter the start values for the first due date, first installment amount, or first installment
percentage, as well as the interval for generating the installment schedule. When you enter these start values
and choose ENTER , the system calculates the installment schedule. It fills the Due Date, Share in %, or Amount
fields according to the calculated installment schedule.
5.1.2.3.2.1 Generate Installment Schedule Automatically

You can create an installment schedule automatically by choosing the Generate Installment Schedule
pushbutton.

When you choose this pushbutton, the Generate Installment Schedule dialog box appears. In this dialog box,
you can enter the start values for the first due date, installment amount, or installment percentage, as well as
the interval for generating the installment schedule.
When you enter these start values and confirm your entries, the system calculates the installment schedule. It
fills the Due Date, Share in %, or Amount fields according to the calculated installment schedule.
5.1.2.3.3 Reinstatement Schedule
In non-proportional business, the reinsurer is liable for a specific loss amount defined by the layer. In return for
assuming this risk, the reinsurer receives a premium, which is negotiated between the cedent and reinsurer.
The reinstatement schedule defines how the partners involved proceed if the entire loss amount is used up. It
specifies the reinstatement premium the cedent has to pay if it wants the reinsurer to renew its cover.
You can create reinstatement schedules only for non-proportional treaty sections that allow reinstatement and
for which a corresponding limit has been set in the premium and liability data.
5.1.2.3.4 Distribution Plan
Definition
The distribution plan defines how the transferred business is distributed to the specified structural
characteristics.
Use
You can use the distribution plan if the functions offered by the installment and reinstatement schedule do not
meet your reporting requirements.
Creating a Distribution Plan in Microsoft Excel and Uploading it to the System
You can also create a distribution plan in Microsoft Excel and upload it to the system. To do this, create a table
with the following columns.
Column 1 Underwriting area
Column 2 Business type
Column 3 Class of business
Column 4 Line of business

Column 5 Accounting unit
Column 6 Company code
Column 7 Share in %
The first row is interpreted by the system as a description and is not uploaded. The system uses only the first
worksheet of an Excel file; data entered on any other sheets is ignored.
Structure
The distribution plan exists in parallel to the installment and reinstatement schedule at section level in Basic
System. You can create a distribution plan only if you have created an installment schedule.
The plan consists of a table containing the following distribution attributes: underwriting area, business type,
class of business, line of business, accounting unit, company code, and share percentage. You select the
distribution attributes from the structural characteristics entered for the section and from the business
partner. You cannot select attributes that are contained in exclusions. You must distribute 100% of each treaty
section.
Lines of business and accounting units are always required entry fields if at least one line of business or
accounting unit is valid for the section being processed. An accounting unit is valid for a section both if the
accounting unit is assigned to the section and if the accounting unit is assigned across several sections.
The distribution key entered at the time the data was posted is always applicable. The system does not transfer
postings when you make a change to the distribution plan.
Integration
Account
In the account, the distribution plan determines how the amount posted is distributed to postings with different
structural characteristics.
Advance Premium
● If there is no distribution plan, the system uses the main structural characteristics or the split distribution.
● If there is a distribution plan, the system calculates the premium as before and then distributes it to the
individual structural characteristics according to this plan.
● The system does not create an original posting or original account over 100% but creates subpostings
only.
Reinstatement Premium
● If there is no distribution plan, the system uses the main structural characteristics or the split distribution.
● If there is a distribution plan, the system calculates the reinstatement premium as before and then
distributes it to the individual structural characteristics according to this plan. In the account, the system
does not create an original posting or original account over 100% but creates subpostings only.

5.1.2.3.5 Non-Proportional Premium
Definition
On the NP Premium tab page, you can enter data about the premium agreements.
The following information is available:
● Fixed premium
● Fixed premium rate (minimum premium rate/maximum premium rate)
● Estimated and final subject premium
● Calculation bases for gross net premium income and losses incurred
● Minimum premium
● Loading factor
You can also enter installment schedules and data about the minimum premium for a specific reinsurer's share.
The general data is then relevant only for the reinsurer shares for which you have not entered any specific data.
You can also indicate on this tab page if a specific reinsurer has agreed a premium-free reinstatement. Use
Use
This data is processed by the Adjust NP Premiums [page 543] background job. You can use this background job
to instruct the system to create accounts for adjustment premiums.
5.1.2.3.6 Limit, Underlying, Deductible (LUD)
Definition
LUDs structure the liability for a layer in the non-proportional treaty.
Use
You can define limits, underlyings, and deductibles (LUD) for each treaty section and assign them to specific
reference categories.
You can also define LUDs across sections and periods, and multiline and multiyear liabilities [page 369].
Examples of these reference categories include losses, loss events, or specific years.
By entering certain structural characteristics, you can limit the validity of the LUD to these characteristics.
If you do not enter a characteristic type, the LUD applies for all characteristics of this type (for example, all
accounting units).

You can use a ranking sequence for the individual entries to calculate their weightings.
In non-proportional sections, the maintenance dialog is not integrated in the non-proportional liability data.
The system processes the structural characteristics that limit the validity of the LUD as follows:
1. Accounting unit (highest priority)

2. Loss class
3. Peril class
4. Area
5. Currency number
 Note
If you enter an accounting unit on the LUD tab page but do not assign this in the posting, the system does
not process the account.
5.1.2.3.6.1 Detailed Description of Limits, Underlyings,

Deductibles (LUD)
If you select the Use in RM checkbox in the treaty header and if the nature of treaty is NPFAC, the LUD fields are
locked.
The following are required entry fields.
Rank LUD Category Maximum Amount Percentage
Section with treaty X X X

type Stop Loss
All other sections X X X
Multiline/multiyear X X X Hidden
limits (at header level)
Once you have entered a rank, LUD category, maximum amount, or percentage (see table) and have confirmed
your entries, the key fields are locked.
The key fields are: Rank, Currency, Exchange Rate Type, Area, Peril, and Loss.
Rank
The rank defines the processing sequence. It is important to enter a rank because of possible
interdependencies and because the result of a calculation at a specific point in time can affect subsequent
calculations.

LUD Category
The LUD category enables a distinction to be made between liability, deductible, and franchise. The
aggregation level of the LUD category is defined by the aggregation category entered for the LUD category.
 Example
The table below contains examples of LUD categories.
LUD Category Name LUD Type Aggregation Category
LIAB Liability Limit Single loss
DEDUC Deductible Deductible Single loss
OCLIA Liability Limit Loss event
OCDED Deductible Deductible Loss event
AAL Annual aggregate limit Limit Treaty period
AAD Annual aggregate deducti Deductible Treaty period

ble
TTLIM Treaty period limit Limit Treaty period
TTDED Treaty period deductible Deductible Treaty period
CREFD Deductible for the loss refer Limit Loss reference

ence
CREFL Limit for loss reference Deductible Loss reference
APLC Deductible for loss classes Limit Loss class
CLCLL Deductible for loss classes Deductible Loss class
FES Franchise for single loss Franchise Single loss
FSE Franchise for loss event Franchise Loss event
MLDED Multiline deductible Limit Treaty + treaty year
MLLIM Multiline liability Deductible Treaty + treaty year
MYDED Multiyear deductible Limit Treaty + section
MYLIM Multiyear liability Deductible Treaty + section
You cannot use the same LUD category for the same combination of currency, area, peril, and loss.

Minimum Amount/Maximum Amount
The minimum and maximum amounts describe the liability limits. If you enter a minimum amount, you must
also enter a percentage.
 Note
Stop loss sections are an exception to this. In this case, the percentage is a required entry.
You can only enter a maximum amount for multiline and multiyear limits (limits).
Percentage
The percentage is applied to the result of a calculation base. The system posts the result under the target entry
code.
If you have entered a percentage, you must also enter the minimum and maximum amounts to which the
percentage applies.
 Note
This does not apply to stop loss sections.
You do not need to enter percentages for multiline or multiyear limits.
Use for Cession Calculation
If you set the Use for Cession Calculation checkbox, the system uses the entry for calculations in Risk Manager.
You do not need to make this entry for multiline and multiyear limits.
Currency
The input help for this field contains only those currencies entered in the currency split. You cannot enter
currencies that are not contained in the currency split.
Area
When a loss occurs, the system checks the loss area against the area covered. Therefore, in this field you can
enter only areas contained in the area split for the section. The input help lists the corresponding areas.

Peril
The peril indicates a possible cause of the loss and creates a reference to the loss.
Accounting Unit
You can restrict an LUD to an accounting unit.
Indexation
If you have entered an index for determining a rise or fall in value in long-tail business (for example, as a result
of inflation) in the non-proportional liability data, you can select an indexation clause for each LUD in the
Indexation Clause field (STD = full index clause, SIC = severe inflation clause).
In the case of a full index clause: If the index value exceeds the margin entered in the non-proportional data, the
difference between the index value and the margin is applied.
In the case of a severe inflation clause: If the index value exceeds the margin, it is applied in full.
Indexation is not possible for multiline and multiyear limits.
Exchange Rates Fixed in the Treaty
If you have agreed specific exchange rates for a treaty that are to be used to translate original currencies in the
NP account into the leading section currency, you can enter these on the Currency Split [page 277] tab page.
Limit Check
You can use the LUD data to perform a limit check during account processing. During this check, the system
checks whether the amounts reported by the cedent meet the limits agreed in the treaty. You can run this
check for proportional and non-proportional treaties.
In proportional treaties, you have to define a calculation base in the LUD data that restricts the specified limit to
the entry codes defined for this base. Calculation bases that are entered for deductibles, franchises, or
underlyings are for information purposes only and are not used during the limit check.
In proportional treaties, you can enter the same LUD categories several times for different calculation bases
and ranks. This enables you to define separate limits on the same aggregation level (such as AAL) for different
calculation bases (such as losses incurred and premiums).
In proportional treaties, you can also select the level to which the specified LUD data applies.

● Original: The system includes the quota share percentage and the corresponding signed line when it
checks the limit. This setting is available in assumed and ceded treaties.
● Treaty: The system includes the corresponding signed line when it checks the limit. This setting is available
in assumed and ceded treaties.
● Share: The LUDs have already been calculated for the relevant share. This setting is available in assumed
treaties only.
The specified fields are not visible in non-proportional treaties. The system includes the specified LUDs with
reference to the aggregation categories when it checks the limit. It also controls the account level for which the
LUDs are valid.
5.1.2.3.7 Clause
Definition
A special agreement contained in a reinsurance treaty, for example NMA1975, PML estimate, 72/168-hour
clause, currency clause, loss advice clause, interest sharing clause.
Use
On the Clauses tab page at section level, you can select the agreed clauses of a treaty from the list of permitted
clauses. When you print a treaty snapshot, you can also print the clauses of the treaty with the accompanying
explanatory text. This information is stored for information purposes only and does not affect system
functions.
You can edit the permitted clauses in Customizing for Basic System under Treaty Edit Clauses .
5.1.2.3.8 Structural Characteristics and Splits
Definition
Structural characteristics indicate the type of coverage offered by the treaty and the details of a posting.
The following structural characteristics are used in SAP Reinsurance Management for SAP S/4HANA (FS-RI):
● Class of Business
● Area
● Business Type
● Line of Business
● Currency
● Peril

Structure
You enter the initial value for a structural characteristic in the header data for the section. If you want to extend
the validity of the section to other values for this characteristic, enter these on the tab page with the correct
name. In this case, the value entered in the header data is the main structural characteristic. The values
entered on a tab page are known in their entirety as a split (for example, area split).
Definition
You define classes of business, areas, business types, lines of business, currencies, and perils, as well as the
hierarchies for these, in the master data.
Hierarchies
You can divide structural characteristics into hierarchies. For example, the area hierarchy node “Europe” can
contain all the countries in Europe.
When you enter a structural characteristic, you can select hierarchy nodes from the input help. The system
automatically splits the subentries (with the exception of area and peril). In the case of manual entries, the
system does not accept hierarchies and nodes. A value or hierarchy must not overlap with the values of the
other split entries. For example, you cannot use the area hierarchy nodes “EU” and “West Europe” if you have
entered “Germany” as the area in both these nodes.
Split
In the split you can define as many valid values for structural characteristics as you want. You can also enter
the percentage share of the class of business, business type, and so on, in the whole section. If you enter this,
the total share percentage must always be 100%.
For more information about the behavior of splits in the posting, see Structural Characteristics in the Posting
[page 282].
Changing the Main Structural Characteristic
If you change the main class of business number, area number, business type number, line of business number,
or currency number, the changed number remains in the corresponding split if this already contains the new
number. If it does not already contain the new number, the system deletes the changed number from the split.
If the original main characteristic is a hierarchy node containing several lower levels (such as the classes of
business 1, 2, 3, and 4), all the split entries remain the same if you change the main characteristic.
Changing the Account Currency
If you select the Crcy Check checkbox in Customizing under FS-RI Reinsurance Basic System Default
Values Edit Defaults for Accounting , the system checks when you change the account currency whether
postings have already been made for this period and section in a combination of original and account currency.
If this is the case, you cannot change the account currency. The system terminates the current process with an
error message.
Deletion Restrictions
If you have created additional values in the split table, you cannot delete the main value.

Integration
Check Uniqueness of Section
When you create a new structural characteristic in addition to the main structural characteristic, the system
checks whether the same combination of class of business, business type, currency, layer, and treaty type
already exists in another section of the treaty and period. In this case, the system rejects the new structural
characteristic and the section remains unique.
A section must be unique if it is to be used in Risk Manager, as otherwise cession calculation cannot take place.
Posting
You can enter postings for a treaty section only for structural characteristics that are contained in this section.
If the section covers several values of a structural characteristic (for example, more than one class of
business), you can either specify directly in the posting for which of these values you want to post data, or let
the system perform the assignment.
For more information, see Structural Characteristics in the Posting [page 282].
Special Features of Areas
If you set the “Area Covered” checkbox, losses in this area are covered by the treaty. If you set the
“Underwriting Area” checkbox, postings can be made to the area. You must define an area either as an
underwriting area or an area covered, and you must set the same checkbox for the checks performed by the
system (for example, for treaties involved).
Special Features of Currencies
Exchange Rate Type
If you change the exchange rate type of the leading currency, the system changes the exchange rate type in the
relevant section.
Exchange Rate for Leading Currency
You can enter the treaty-specific exchange rates for currencies on the currency split tab page for the leading
currency for the section.
The exchange rates fixed in the treaty are included in the non-proportional account. Loss postings in the
corresponding currency are converted into the currency in the LUD data based on these fixed rates (leading
section currency). The system then calculates deductible, liability, and so on.
These fixed exchange rates are also used to calculate reinstatements.
Currency-sensitive LUDs are not used here if the specified currency differs from the leading section currency.
You cannot enter treaty-specific exchange rates for wildcard entries in the currency split.
Changing the Share Currency and Currency Handling
If you select the Crcy Check checkbox in Customizing under FS-RI Reinsurance Basic System Default
Values Edit Defaults for Accounting for the corresponding company code, the system runs the following
checks:
● If the currency handling in a partner involved is set to share and you want to change the share currency, the
system checks whether this share has already been posted in this period using the account currency. If this
is the case, you cannot change the share currency.

● Changes to the account recipient or share currency can be copied to older periods when you save the data.
If, however, postings have already been made in one of these older periods in the share currency, the
system does not change the share currency in the affected period.
● You cannot change the currency handling if there are already postings for this share.
Locked for Deletion
If the currency you want to delete is still being used in the installment schedule, LUDs, XL fca, or the result-
dependent conditions, you cannot delete it from the currency split.
Deleting Structural Characteristics That Have Postings
Structural characteristics that have postings (class of business, line of business, area covered, underwriting
area, currency, business type, peril) cannot be deleted from a Risk Manager policy (RM policy) or from Basic
System (treaty). In this case, the system checks in the background whether there are postings for the
structural characteristics that you want to delete. If this is the case, the system terminates the current process
with an error message.
 Note
The system includes both Risk Manager and Basic System accounts in the treaty check.
Special Features of Classes and Lines of Business
Selecting Class or Line of Business
In Customizing for Basic System under Default Values Edit Defaults for Accounting (Calculation Fields) ,
you can specify whether values are split according to classes or lines of business.
Main Classes of Business
Main classes of business are used to group classes of business for evaluation purposes. If the settings in
Customizing specify that all classes of business for a section must belong to the same main class of business,
you can only select those classes of business assigned to the same main class of business as the class of
business originally entered.
In Customizing for Basic System, you can use the following activities to manage main classes of business:
● Treaty Classes/Lines of Business Edit Main Classes of Business

● Treaty Classes/Lines of Business Assign Main Classes of Business
● Default Values Edit Defaults for the Section Level (CoB-MCoB checkbox)
Accounting Classes of Business
Accounting classes of business are used to group classes of business for accounting purposes.
In Customizing for Basic System, you can use the following activities to manage accounting classes of
business:
● Treaty Classes/Lines of Business Edit Accounting Classes of Business

● Treaty Classes/Lines of Business Assign Accounting Classes of Business
Entry of Line of Business Split
If you do not enter a main line of business in the section, the line of business split is not ready for input.

5.1.2.3.8.1 Exclusion of Structural Characteristics/
Combinations in a Treaty
Definition
When you create exclusions in an FS-RI treaty, a structural characteristic in a covered hierarchy is excluded
from coverage, or structural characteristics that are covered individually are not covered in conjunction with
each other (see below).
Use
You use exclusions to restrict the coverage of a non–portfolio treaty or a Risk Manager policy.
For more information about exclusions in Risk Manager policies, see Exclusion of Structural Characteristics/
Combinations in a Policy Section or Participation [page 132].
Options
● Individual areas, classes and lines of business (only the end nodes of a covered hierarchy node, such as
"Europe Without Switzerland")
● Combinations of structural characteristics, for example coverage of fire and water damage in the United
States, Mexico, and Canada, but excluding the combination "Fire in Mexico"
● A Risk Manager policy contains additional exclusions to those in the master treaty reinsuring the policy
Constraints
● The treaty section must not be fully excluded. The section must contain at least one combination of entries
from the respective split tables that has not been excluded. Any given split table entry may be excluded
only once in conjunction with the same entries.
● Taking the exclusions into account, the main characteristics and combination of split table entries for a
section must remain unique.
● You must make sure that at least one combination of all the main structural characteristics is available at
any given point in time.
● You cannot exclude split table entries that contain percentage values.
● You can exclude business types only in conjunction with other user-defined structural characteristics.
● You cannot exclude hierarchies if an individual end node within the hierarchy has already been excluded.
● Basic System Risk Manager : In Basic System you cannot exclude any values that have already been
created in Risk Manager. This applies if you have already assigned a policy to the master treaty and have
then made changes to this master treaty. The system checks this when you set the status of the treaty to
In Force.
Time Limit
You can also restrict the time period for which exclusions apply. In this case, the system checks each posting to
determine whether it is permitted for the specified time. By default, an exclusion rule is valid for the entire
treaty period.

You cannot enter a time limit for exclusions if the treaty is marked for use in Risk Manager. This is the case if
you have set the Use in RM checkbox in the treaty header data. In the same way, you cannot use treaty sections
containing exclusions with time limits in Risk Manager.
Structure
You create exclusions on the Exclusions tab page at treaty period level.
Integration
● You cannot split, release, or retrocede accounts and postings that contain excluded characteristics (or an
excluded combination of characteristics). Treaties that are linked with treaties having excluded
characteristics (or a combination of these) must have at least the same structural characteristics as the
assigned treaty. When it checks this, the system also takes exclusions into account. This affects treaties
linked by:
○ Reinsurance program
○ Participating treaties
○ Retrocession/assumed treaty assignment
● You cannot assign losses to a section in which a structural characteristic (or a combination of structural
characteristics) containing the loss has been excluded.
● When transferring accounts from Risk Manager to Basic System, if the system finds accounts that are not
covered given the restricted exclusions, it does not transfer these and logs this data.
5.1.2.3.8.2 Structural Characteristics in the Posting
If the section contains more than one value for the structural characteristics Class of Business, Area, and Line
of Business, the system assigns these as follows.
Structural Characteristic Specified in the Posting
The system posts to the specified value.
No Value Specified in the Posting
● If you do not enter percentages for the individual values:

The system posts the entire amount to the main structural characteristic.

● If you do enter percentages:
The system splits, and then posts, the amount according to these percentages. In doing so, it deletes the
original posting and creates corresponding subpostings. This is done when you save the account.
Hierarchy Node Specified in the Posting
If you enter percentages in the split, the system splits these percentages accordingly, taking into account only
the values underneath the hierarchy node.
 Note
● If the settings in Customizing specify that the system transfers the main structural characteristic to the
account, you must delete this characteristic when creating the posting to allow the posting to be split.
You make this setting in external Customizing for Basic System under Default Values Edit Defaults
for Accounting .
● The system always splits postings either according to line of business and area or according to class of
business and area. In Customizing for Basic System under Default Values Edit Defaults for
Accounting (Calculation Fields) , you can specify whether values are split according to classes or lines
of business.
5.1.2.3.9 Accounting Unit
General Definition of Accounting Unit
For more information about defining, creating, and assigning global and local accounting units in the treaty,
see:
● Create or Change a Local Accounting Unit [page 289]

● Create or Change an Accounting Unit (Section Assignment) [page 285]
Accounting Units in the Posting (General)
● You can use a local or global accounting unit for each posting, if an assignment exists in the respective
treaty.
● If this is a local accounting unit, the system determines the assigned global accounting unit from the local
accounting unit.
Accounting Units in the Posting (Life)
If the account is based on a life treaty, you must enter an accounting unit to be used to determine the class and
line of business as you cannot enter these specifically.
Accounting Units in the Posting (Non-Life)
● If the treaty class is “Non-Life”, you can enter an accounting unit.

● You must enter the class and line of business as these are not determined from the accounting unit used.

5.1.2.3.9.1 Accounting Units
Use
When you double-click a node, the system opens a tab page for defining accounting units for this node on the
right-hand side of the screen. If the substructure of the family up to this node contains a company code-
dependent attribute, you must first assign at least one company code to the node. You do this on the
“Company Codes” tab page, which is to the right of the current tab page. If none of the attributes are
dependent on the company code, you can define the accounting units straight away.
The internal number of the accounting unit and the short text must be unique, and both fields are mandatory.
The name of the accounting unit is freely definable. The “Company Code” field is only ready for input if the set
of attributes to be assigned values contains a company code-dependent attribute. This field is then a required
field, and can only be changed if values have not yet been assigned for the accounting unit. Once values have
been assigned, the field is locked.
Features
Header
The header area displays the short and long texts for the family, as well as the attributes of the node for which
the accounting unit is being entered.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode you can create accounting units, or
change the short and long texts of existing accounting units. If the accounting units are dependent on a
company code, you can also change the assigned company code, as long as you have not yet assigned
values to the accounting unit. You cannot change the internal number of existing accounting units (primary
key).
● Delete
This pushbutton is active only in change mode and can be used to delete existing accounting units that
have not yet been used in a treaty.
● Create
This pushbutton is active only in change mode. It determines the next available accounting unit number in
the sequence and writes this to the next free line in the table control.
● Translate
This pushbutton is active only in change mode. You apply this function by selecting at least one accounting
unit in the table control. This opens a dialog box prompting you to select the target languages. A second
dialog box then appears for the translation itself.
5.1.2.3.9.1.1 Assign Accounting Units to Sections
You can refine the structure of a section in a reinsurance treaty by assigning accounting units. You can assign
both local and global accounting units to sections.

You can assign an accounting unit to one specific section or to all the sections in the period. To assign the
accounting unit to all the sections in the period, leave the Section field empty.
Tab Page Features
If you enter new global accounting units while the system is processing a treaty, these new accounting units are
not listed in the input help. To transfer all the changes made in the transaction for defining global accounting
units, choose the Update Accounting Units pushbutton.
You can change the assignment of an accounting unit to a section as follows:
● Double-click the assignment to be changed

● Choose Change in the context menu
An additional window is displayed in which you can change certain data for the assignment.
To delete all the existing assignments, choose Delete All in the context menu of the first node in the tree
structure.
To delete a specific assignment, choose Delete in the context menu of the relevant assignment.
Possible Actions
● Create
You can create an assignment.
● Change
You can change an assignment.
● Delete
You can delete an assignment.
5.1.2.3.9.1.1.1 Create or Change an Accounting Unit (Section

Assignment)
You control the input help using the Local Accounting Unit checkbox. If you activate this checkbox, all the local
accounting units are listed in the input help for the accounting unit. If you do not activate this checkbox, all the
relevant global accounting units are listed in the input help.
You can assign the accounting unit to a specific section in the current period by entering this section in the
Section field. If you leave this field empty, the system assigns the accounting unit to all the sections in the
current period.
A section must always be covered in full by accounting units.
Each assignment has a validity period in which you can enter accounts in the accounting unit for the assigned
section.

5.1.2.3.9.1.2 Processing of Accounting Units in Forecast and
Estimation
Use
You can restrict a forecast or estimation to postings within certain accounting units.
Features
Non-Life Treaty
If you have not specified an accounting unit for forecast and estimation rules and the treaty is a non-life treaty,
the system processes postings irrespective of the accounting unit value of the respective posting.
If, after processing the forecast and estimation rule, the system generates postings in a background job, the
accounting unit values are based on the accounting units specified in the rule. If you have not specified
accounting units for the rule, the system stores the posting without accounting units.
Life Treaty
In a life treaty, the system assigns to the target posting the accounting unit to which the respective calculation
bases were applied.
Example
You have a quota share treaty and have assigned two global accounting units to a section in this treaty.
This treaty contains three forecast rules; two for each accounting unit and one without a specified accounting
unit. Each of these is a year-end forecast with the following details.
Details for Forecast Rule
Rank Amount Percentage Reference Year Comparative Accounting Unit

Method
1 1000 0 None Every difference AU1
3 1400 0 None Every difference
You then run the background job for forecast and estimation with the following settings.
Accounting Period: YEAR
Usage: Y, F
Accounting Year: 2000

Financial Year: 2300
Month: 03
Detailed Log: Yes
The system generates an account with three loss payment postings for the underwriting and occurrence year
2000.
Amount for AU1: 1000
Amount for unspecified accounting unit: 1400
5.1.2.3.9.2 Global Accounting Units
Definition
This section introduces the concept of the families and their structures, which form the framework for defining
accounting units.
Structure
Families and Treaty Classes
The top level consists of families. Each family represents an entire structure. You can define as many families as
you want.
Each family is assigned to one or more treaty class, and one or more treaty type.
This assignment determines the treaty management context in which the accounting units configured under
the nodes for a family can be used.
The treaty class indicates the type of treaty (for example, non-life), while the treaty category defines whether
the treaty is proportional or non-proportional.
The node structures are contained under the families. The second level below a family can have exactly one
node, which is the first node in a structure and always assigned to a family. This is the top node.
Each family can only reference one top node.
Nodes
For each top node, you can create several nodes at the next levels.
You can assign exactly one attribute to each node.
An attribute corresponds to a field in an existing operative database table. This restricts the available value set
for an attribute.
The available attributes are read from a special Customizing table, containing fixed attributes.

You can define a subset of these attributes and use it to define the structure. You can specify the treaty class
for which the attributes are valid.
You can also select attributes that have already been assigned and used as “no longer available”.
You define the usable attributes in a separate Customizing activity.
Accounting Units
You can define several accounting units for each node in a family structure. The function of a node is identical
to that of a class, which defines the features of an accounting unit (object).
The features refer to the accounting unit attributes that need to be assigned values.
These are all the attributes in a substructure, from the top node down to the node for which the accounting unit
has been defined.
When you define an accounting unit, the system creates an instance (object) of the node or of the attributes to
be assigned values. You must assign values to these attributes.
You can define several accounting units for each node, but each one must have a unique name.
Each node must be assigned to at least one company code. This defines the validity area of the accounting unit.
 Note
In special cases, one of the attributes to be assigned values may be dependent on a company code. In this
case, you must specify a company code for each accounting unit in order to call up the permitted values.
Accounting Unit Value
Once you have defined an accounting unit, you must enter values for all the attributes.
You can do this either by selecting a predefined value for this attribute or by entering a number in the case of
numerical attributes. Both entry methods are mutually exclusive.
A given attribute/value combination can only be defined once for each node. In other words, you cannot define
an accounting unit twice under the same node.
This check is only necessary for the node containing the accounting units, since the accounting units under the
other nodes cannot have the same types of attributes.
5.1.2.3.9.3 Local Accounting Unit
You can use accounting units to refine the structure of a section in a reinsurance treaty. Unlike global
accounting units, a local accounting unit is visible only in the treaty in which it was created.
You create a local accounting unit based on a global accounting unit. In other words, you must enter a global
accounting unit when you create a local accounting unit. This means that the local accounting unit has all the
attributes and values of the global accounting unit.
For the local accounting unit, you have to create at least one additional attribute and a value.
The system displays the following information in the tree control:
● Root node: The name of the accounting unit family used in the treaty

● Level 1: The short and long text for the local accounting unit
● Level 2: The short and long text for the global accounting unit used to create the local accounting unit
● Level 3: The attributes and values of the global accounting unit
● Level 4: Additional attributes and values of the local accounting unit
Tab Page Features
If you enter new global accounting units while the system is processing a treaty, these new accounting units are
not listed in the input help.
To transfer all the changes made in the transaction for defining global accounting units, choose Update
Accounting Units.
You can change an existing local accounting unit as follows:
● Double-click the accounting unit

● Choose Change in the context menu
An additional window appears in which you can change specific data for the local accounting unit.
To delete all the existing local accounting units, choose Delete All in the context menu of the first node in the
tree structure.
To delete a local accounting unit, choose Delete Local Accounting Unit in the context menu of the relevant local
accounting unit. This entry is displayed in the context menu at all four local accounting unit levels.
Possible Actions
● Create
You can create a local accounting unit.
● Change
You can change a local accounting unit.
● Delete
You can delete a local accounting unit.
5.1.2.3.9.3.1 Create or Change a Local Accounting Unit
You create a local accounting unit based on a global accounting unit. This means that the local accounting unit
has all the attributes and values of the global accounting unit. For a local accounting unit, you have to create at
least one additional attribute and a value. This means that the local accounting unit is more specific than the
global accounting unit on which it is based.
The number of the local accounting unit must begin with “L_” and be unique in the treaty.
You can use only global accounting units that belong to an accounting unit family to which the relevant treaty
class has been assigned.
Similarly, you can only choose attributes that are assigned to the relevant treaty class as an additional attribute
for the local accounting unit.

Dialog Box Features
When you call the dialog box to create a new local accounting unit, the system prefills the accounting number
field. You cannot change this number once you have entered a name for the new local accounting unit and have
confirmed this entry by choosing ENTER .
To remove the global accounting unit from the Accounting Unit field, choose the Delete Global Accounting Unit
pushbutton. You can then make a different entry in this field.
If you have entered an additional attribute and want to delete it, select the relevant entry and choose the Delete
Row pushbutton.
5.1.2.4 Reserves
Definition
Reserves are amounts that are set aside for clearing receivables expected in the future.
Use
For example, you use reserves if you are a reinsurer who is aware of a loss for which you are liable but for which
the cedent has not yet invoiced, perhaps because it does not yet know the exact amount of the loss.
You can use the result-independent conditions to manage several reserves at the same time and process them
in accounting. In Germany, for example, you need to create reserves for financial accounting as well as
statistical reserves (= data for the client accounting period). The unearned premium is calculated differently in
each case. Either 100% or 92.5% of the commission is deducted.
For portfolio calculations it is also useful to have a third type of unearned premium that enables you to deduct
the agreed premium for portfolio entry instead of the posted premium.
Structure
You create a reserve as a result-independent condition with the category “Other”.
The current loss reserve balance is the total of the opening and closing reserves. You must enter claims
notifications, and any changes to these, as postings.
Once you have calculated the reserves for each account using the Split function, you can create a provisional
balance sheet for the current financial year. You can enter only one entry code for financial accounting, and one
for statistical purposes (client accounting period).
However, there is no limit to the number of other reserve types. These other reserve types can be used as the
basis for the portfolio calculation. In this case, you need to make sure that you enter the correct offsetting
posting for the closing reserves for the portfolio withdrawal.

5.1.2.5 Log for Client Accounting Period
Use
A client accounting period (CAP) is a cedent's accounting period and, as such, the period in which the cedent
groups together their postings. You control the length of this period in the Accounting Frequency field in the
treaty header data.
You can use the CAP log to control and check the chronology of existing and future accounts for every cedent
accounting period. Each entry in the CAP log displays the number of final accounts, estimated accounts, and
reversed estimated accounts for each account cedent/treaty/treaty section/accounting year/accounting
period.
 Note
Risk Manager (Life) does not display counter readings.
Integration
You can recalculate the counter readings in the CAP log at any time using the Determine Counter Readings in
CAP Log background job. You can start the background job in Schedule Manager under accounting functions.
 Note
You may need to run this background job if you have imported released accounts via an interface. The
system updates the counter readings only when you call the Release Account function.
Prerequisites
You have defined in Customizing whether this is a final, estimated, or reversed estimate account. You have used
the Customizing activity Edit Combination of Actual and Estimate for CAP Log to assign the combination of
actual and estimate indicators to the counters in the CAP log.
You can enter only one combination of actual and estimate for each counter. Based on the value of the actual/
estimate indicator for an account, the system uses the combination of actual and estimate to update the
corresponding counter in the CAP log.
 Caution
The set of actual/estimate indicators that are contained in the individual combinations of actual and
estimate must not overlap.

Activities
You can access the CAP log as follows:
● Switch to the CAP Log tab page at leader level in the treaty (Basic System Life and Non-Life). The system
displays only those accounts for the selected treaty.
● Choose Account Close CAPs (transaction /MSG/R_ACAP). If you leave the Treaty Number field
empty, the system displays the accounts for all the treaties for the cedent.
 Note
This means you can close CAPs in Risk Manager (Life) if no accounts exist.
The system creates an entry in the CAP log when you create an account for the treaty in Basic System
(provided this is not an FGU account or a preliminary account). When you release an account in Basic System,
the system increases the counter in the CAP log for final, estimated, and reversed estimate accounts by 1 for
each account; if you reverse an account, it lowers this counter by 1.
The system updates the log when:
● You create, change, or close a CAP in the Risk Manager (Non-Life) account.
● The system automatically creates an initial open client accounting period for each section of a life treaty. If
you set the Use in RM checkbox, the system creates an initial open client accounting period only for the
oldest generation assigned to a section.
○ This applies only if:
○ The Use in RM and Account Transfer from RM checkboxes are selected
○ The Accounting Frequency field is filled
○ You have switched to the CAP Log tab page to create the first CAP log.
 Note
However, at the earliest the validity start date of the first open CAP can be the same as the start date of
the corresponding treaty.
More Information
Determine Counter Readings in CAP Log [page 556]
5.1.2.6 Data Specific to Life Insurance
Life insurance differs from non-life insurance in a few areas. For this reason, the FS-RI system offers additional
functions for life insurance treaties and data fields with their own tab pages.

5.1.2.6.1 Product Overview in Life Treaty
Use
On the Products tab page, you can assign product codes and the associated cedent subproducts to the current
treaty. You must define these for each cedent in cession handling/product maintenance.
You assign a valid product code to the treaty by entering a product code, the product code version, and the
valid-from date of the product code. You can make further specifications by entering a cedent subproduct, a
name, the version, and the valid-from date of the cedent subproduct.
Column Description
In the Product Code column, you enter the name of a product code; this identifies the product.
The Product Name column displays the “brand name” of a product code as a supplement to its name; you
cannot make an entry in this field as it is provided for information purposes only.
In the Product Code Version column, you enter the version of the product code. The version is used to
differentiate between products with the same short name (in the Cedent Product column).
In the Product Code Validity Begin column, you enter the start date for the validity period of the product.
If you want to assign a cedent subproduct, you enter the name in the Subproduct Code column in the same way
as for a product code. This name identifies the cedent subproduct.
The Subproduct Name column displays the “brand name” of a cedent subproduct as a supplement to its name;
you cannot make an entry in this field as it is provided for information purposes only.
In the Subproduct Code Version column, you enter the version of the cedent subproduct. The version is used to
differentiate between cedent subproducts with the same name (in the Subproduct Code column).
In the Subproduct Code Validity Begin column, you enter the start date for the validity period of the subproduct.
Features
The standard functions include: inserting and deleting a row, sorting the product codes, selecting and
deselecting all rows containing product codes, and the positioning of specific product codes.
Constraints
● If a product code has been created without a cedent subproduct, you cannot enter a cedent subproduct to
subdivide this product code.
● If a product code has been assigned a cedent subproduct, you can only assign different cedent
subproducts to this product code. You cannot enter the product code again without specifying the cedent
subproducts.

5.1.2.6.2 Set of Attributes Overview
The “Set of Attributes” tab page displays the “sets of attributes” for the current treaty. All the defined sets of
attributes are displayed on the left; you can display or hide the names of the attributes contained in these sets
by expanding or collapsing the relevant folder.
In the default display, the attributes are hidden.
The attribute names, operators, and values appear only when you expand a “set of attributes”.
The Condition field groups all operators and values together in one column. You can hide the individual
operator and value fields, and change the field sequence.
To delete a “set of attributes”, select the relevant set of attributes and choose Delete Selected Sets. The system
deletes the selected attribute only if this is not being used by conditions in the treaty.
If you choose Delete All Unused Sets, the system automatically finds all “sets of attributes” and deletes only
those that are not being used by a condition in the treaty.
This means that you can clean up the “sets of attributes” so that only those actually in use remain.
5.1.2.6.3 Cession Handling
On the “Cession Handling” tab page, you manage and enter data for controlling cession processing,
retrocession, and the account in a single-risk management module. This data is regarded as treaty rules.
You can use these rules to control:
● The assignment of a policy to a specific treaty generation (important for processing in the account and in
the retrocession)
● Forward and backward booking processes in the account
● The calculation of audit values for comparing the cedent’s calculations with your calculations in a single-
risk management module
5.1.3 Working with Treaties
SAP Reinsurance Management for SAP S/4HANA (FS-RI) offers the user a range of functions that make it
easier to work with treaties or provide extended options for processing an account.
For more information, see the individual sections.
5.1.3.1 Responsibilities
Use
You use this function to specify which users can perform which actions in a treaty.

Prerequisites
The system needs to know which users are available for selection. There are two ways of doing this:
● Create an organizational structure in SAP Organizational Management (SAP PD-ORG). For more
information, see the documentation for SAP PD-ORG.
● Create individual employees as business partners ("person"). For more information, see the
documentation for SAP Business Partner (SAP BUPA).
Features
All users with a role for which the “Active Treaty” checkbox is set in external Customizing for Basic System
(under Basic Settings -> Authorizations -> Edit Responsibilities for the Treaty) are authorized to perform treaty
management.
Exclusive Responsibility
In Customizing, you can specify whether a role can be held by one or more people. You make this setting in
external Customizing for Basic System under Basic Settings Authorizations Edit Responsibilities for the
Treaty using the Unique Treaty checkbox.
This setting is also effective at loss and account level.
5.1.3.2 Creating Treaties
Use
You create a treaty if you want to map a business relationship with a cedent or with a reinsurer or
retrocessionaire.
Prerequisites
● You have created the partners involved as business partners with the necessary roles.
● If you are not using the organizational plan in SAP Organizational Management (SAP PD-ORG), you have
created the persons responsible in your company for a treaty, account, and loss, as business partners.
● If you are using SAP PD-ORG, you have assigned the roles “Responsible for Treaty”, “Responsible for
Account” and “Responsible for Loss” to the corresponding policy sections.
● You have selected a company code in which you want to work. The system assigns the treaty to this
company code.
● You have defined different fields as required entry fields, optional entry fields, or hidden fields in external
Customizing for Basic System under Treaty -> Field Modifications.

Procedure
1. In the user menu, select FS-RI: Reinsurance Basic System Treaty Life or Non-Life Create .
2. Select the company code in which you want to work.
3. Assign a treaty number or leave the corresponding field empty; the system uses internal number
assignment to assign a number from the number range interval defined in Customizing for Basic System
under Treaty Edit Number Ranges .
4. Enter the treaty category and nature of treaty.
5. Choose New or Create with Template. For more information about working with templates, see Copying
Treaties [page 301]).
6. The header data for the treaty appears. Enter the cedent and a name for the treaty.
7. Enter the header data for the treaty.
8. Save the treaty.
 Note
If at least two periods exist, a period has the status Posting Allowed, or accounts exist for a period, the
following fields are locked: Treaty Category,
Nature of Treaty
, Treaty Effective From,
Term in Months,
Merged With
, Section Unique, Account Transfer.
The system locks these fields as soon as an account is created for the treaty in order to guarantee the
consistency of the account data. The system also locks the Treaty Category and Nature of Treaty fields
when you create a share or section to ensure data consistency.
The End of Financial Year field is locked:
● As soon as you create a fixed time block that is shorter than the corresponding period and ends with
the end of the financial year or the end of the period
● As soon as an account is created for the treaty
Result
You have created a raw version of a treaty and can now enter the relevant treaty data.
5.1.3.3 Treaty Calendar
Use
You use the treaty calendar to manage the dates for a treaty.

Prerequisites
In Customizing (under Default Values Edit Defaults for Treaties ) you can define a default value for the
From and To fields for each company code. These values specify how many days the dates are displayed in the
past or in the future as soon as you select the Treaty Due Dates tab page.
If you do not make an entry here, the dates are displayed from the current date for one year in the past and in
the future.
In Customizing under Treaty Enter Date Types for Treaty you define all the dates that you want to
generate or that can be created manually.
The following information is required:
● Date Type ID/Short Text/Long Text: Unique key for a date type; short and long text for the defined date
type.
● Assignment Level: ID of the assignment level assigned to the date. The assignment level specifies whether
a date is created for the treaty header, the treaty period, a partner involved, a treaty section, a result-
dependent condition, or a distribution plan.
● Responsibility: A responsibility can be assigned to a date. This responsibility determines who is responsible
for the date type.
● Generation Routine: If you enter a generation routine, this date is generated automatically. The following
generation routines are available:
○ /MSG/CL_R_V_APP_GC_DEPPREMPLAN: The generation routine generates dates for the due date of
advance premiums in accordance with the installment schedule. The system determines the due dates
of the premium installments and displays these as dates.
○ /MSG/CL_R_V_APP_GC_RESUBMIS: The generation routine generates a date for the resubmission
date for a treaty header. The system determines the resubmission date of the treaty.
○ /MSG/CL_R_V_APP_GC_CANCEL_TTY: The generation routine generates a date for the next possible
cancellation date for a treaty. The cancellation date is determined taking into consideration the
specified cancellation type and the cancellation date used for this type within the treaty year. The
system deducts the specified cancellation period and generates a date. If the selection period is after
the treaty end date, the system does not generate any dates of this type.
○ /MSG/CL_R_V_APP_GC_ACC_CRT_PER: The generation routine generates dates for the due dates for a
treaty’s accounts. The system adds the number of days of the specified account creation period,
taking into consideration the “days per year” rule of the affected business partner at the end of each
relevant account period. The accounting period is determined from the account creation period, the
accounting frequency, and the financial year end. This only includes accounting frequencies that are
after the treaty start date.
○ /MSG/CL_R_V_APP_GC_RESDEPCOND: The generation routine generates dates for each due date for a
treaty’s result-dependent conditions. The due date is calculated based on the end date of the
corresponding period, the accounting frequency, the calculation period and the adjustment period of
the result-dependent condition, and the account creation period of the treaty. The system creates
dates based on the accounting frequency that lie between the minimum and maximum date:
○ Minimum date: end date of the period + calculation period + account creation period
○ Maximum date: end date of the period + adjustment period + account creation period
If an accounting frequency has not been entered, the system applies the accounting frequency
“Annually”.
○ /MSG/CL_R_V_APP_GC_CANCEL_INV: The generation routine generates a date for the next possible
cancellation date for each partner involved for a treaty. The cancellation date is determined taking into

consideration the specified cancellation type from the treaty header and the cancellation date used for
this type within the treaty year (entered for the partner involved). The system deducts the cancellation
period specified in the treaty header and generates a date. If the selection period is after the treaty end
date, the system does not generate any dates of this type. Moreover, if the determined cancellation
date no longer falls in the current period of the calendar year, the system does not display any date of
this type.
If you require other automatically generated dates, you have to create the generation routines for these.
When you create a new generation routine, you have to make sure that this is inherited by the superclass for
the relevant business object (BO).
The following superclasses are available: BO Treaty - /MSG/CL_R_V_APP_GC_BASIC
You must redefine each of the following methods when you create a new generation routine:
● do_set_tabname: This is where you enter the table name of the required assignment table (in
Customizing under Enter Assignment Levels for Treaty Due Dates). Before you can use the generation
routine for a specific date type, the specified table must match the assignment level.
● do_process_data: You must implement the processing logic for each generation routine that determines
the required date from the corresponding treaty level. We recommend that you use the corresponding X
structure of the treaty level and the date type as the input structure. We recommend that you use a date
and the corresponding assignment of the date to the required level as the output structure.
 Example
Generation routine /MSG/CL_R_V_APP_VZ_PREM for the treaty level “installment schedule” generates
a date and creates the due date.
do_set_tabname: set table /MSG/RTAPPVZAL (assignment table for advance premium)
do_process_data
Input structure: /MSG/R_APP_GC_VZ_PREM_IN (consists of the table for the installment

schedule /MSG/RX_VZ_PLAN_ITAB and date type /MSG/RX_APP_TYPE_ID)
Output structure: /MSG/R_APP_GC_VZ_PREM_OUT (consists of the table for dates /MSG/

RX_T_APP_ITAB and the table for the assignment level /MSG/RX_T_APP_VZ_AL_ITAB)
Features
The dates are generated as soon as you select the Treaty Due Dates tab page. You use the From and To fields to
specify the period for which you want to generate the dates.
The system updates the display when you change the entry in one of the fields.
You can also enter dates manually by choosing Add New Date. You can change or delete dates that you enter
manually. You have to enter different values depending on the date type and assignment level. This is necessary
so that you can assign a date to one section, for example.
To create a date, you must always enter the date type and the date. A comment can then be assigned to this
date.

 Caution
Automatically generated dates cannot be edited.
 Note
Due date of a result-dependent condition: If you want to enter a date for the due date of a result-dependent
condition, you must select the relevant condition in addition to the date type and assignment level. You can
use the input help to do this.
A new method (DO_FILTER_RESPONSIBILITY) has been added to the current Business Add-In (BAdI) for the
treaty. You can use this method to filter the generated date types by responsibilities.
5.1.3.4 Deleting Treaties
Prerequisites
When you want to delete a treaty, the system performs various checks. For more information, see Checks
Performed by the System When Deleting a Treaty [page 300].
Procedure
1. In the FS-RI role menu, choose Create Treaty, Change Treaty, or Display Treaty.
2. Enter the number of the treaty to be deleted. You can also use wildcards (* and ?).
3. Choose .
4. Select the treaty in the table and choose .
Results
The system archives the treaty and displays it as deleted.

5.1.3.4.1 Checks Performed by the System When Deleting
a Treaty
Use
When you delete a treaty, the system performs a number of checks to ensure that data is kept consistent. It
checks the treaty itself, as well as lower-level periods, sections, and shares.
Features
Treaty
● The treaty must not be in use in other treaties. This means it must not be used as a retrocession treaty, an
XL fca treaty, an assigned treaty in the compensation rules, a participating treaty in the share of another
treaty, a merger treaty, in a loss assignment, or in the treaty calculation rules.
● The treaty must not have an account that is “Pending”, “To Be Split”, or “Released”.
Period
The treaty must not contain any periods with a status that allows posting.
Sections
The system checks whether a section is used as a retrocession section, is assigned to a compensation rule, is
used as an XL fca section, or is part of a loss assignment. However, it displays an error message only if the
period of the treaty, in which the treaty to be deleted participates, has a status that allows posting.
Shares
The system checks whether a share in the treaty to be deleted is used in a compensation rule. If the period of
the treaty, in which the treaty to be deleted participates, has a status that allows posting, the system does not
delete the treaty.
5.1.3.5 Copying Treaties or Parts of Treaties
You can use these functions to copy data to a target object at treaty, period, share, and section levels.
If you are copying data to an existing target object, the system does not overwrite existing data.

5.1.3.5.1 Copying Treaties
Prerequisites
● In Customizing for Basic System under Default Values Edit Defaults for Copying Treaties , you have
specified whether a standard treaty or a treaty template is used to copy treaties. A treaty template is a
treaty in which the Treaty Template checkbox is set for the treaty category. You cannot post data to a treaty
template or link it to other treaties as part of retrocession or as a participating treaty, for example.
● The source and target treaty do not have the status “Deleted”.
● The status of the source period is not “Canceled” and is not “Posting Allowed”.
● The copied periods do not overlap with any existing period in the target treaty.
For more information about accounting units, see "Accounting Units in the Copied Treaty".
Context
You use this procedure to copy data from one treaty to another. The system does not overwrite existing data in
the target treaty. The target treaty can be in a different company code to the source treaty.
Procedure
1. Open the Copy Treaty screen by choosing FS-RI Reinsurance Basic System Treaty Copy Treaty .
2. Enter the required data.
3. Confirm your entries.
4. The system copies the treaty. Note the following:
○ The system copies the tables containing sliding scale data, result-dependent conditions, result-
independent conditions, portfolio rules, and the reinstatement schedule only if these tables do not yet
contain any data in the period to be copied.
○ The system copies only the most recent entries in the tables for retrocession, accounting units,
participations, result-independent conditions, or conditions, if these tables have the same key data
(with the exception of the Valid-From and Valid-To fields).
○ The system sets the status of the target periods to the highest existing status and deactivates the
Posting Allowed and Canceled checkboxes. The status is assigned the number “999 COPY”
(predefined in Customizing); you must not change this status as it is entered to prevent potential data
inconsistencies. The system does not check the successor statuses at treaty period level here. For
more information, see Treaty Period [page 211].
○ The system does not copy any notes that may exist for the treaty.

5.1.3.5.1.1 Accounting Units in the Copied Treaty
Copying a Treaty Within a Company Code
When you copy a treaty within a company code, you can include local accounting units and assignments to
global accounting units.
Copying a Treaty Across Company Codes
Local Accounting Units
When you copy a treaty across company codes, you cannot include local accounting units.
Global Accounting Units
When you copy a treaty, the system can also include references to global accounting units in the treaty and the
validity periods of these references, provided you have made the necessary settings in Customizing. The
system does not copy the percentages for assignments.
You make these settings in external Customizing for Basic System under Default Values Edit Defaults for
the Copying of AUs Across Company Codes .
Dependent Objects
The system also copies result-independent conditions, LUDs, and the forecast and estimation data assigned to
accounting units if the accounting unit to which they are assigned is entered in the target treaty.
5.1.3.5.2 Copying Treaty Periods
Use
You can copy one treaty period to another within a treaty. The system creates the corresponding period if it
does not exist in the target treaty. If the target period already exists, the system does not overwrite existing
data.
Prerequisites
● The source treaty does not have the status “Deleted”.

● The copied period does not overlap with any existing period in the target treaty.

Procedure
Alternative 1
1. At treaty header level, go to the Periods tab page.

2. Choose Copy Periods.
3. The system checks whether it has to create a new period or whether data is to be copied to an existing
period.
4. The system copies the data. This includes sections, partners involved, and the lower levels, as well as the
external references.
Alternative 2
1. In the FS-RI role menu, choose FS-RI Reinsurance Basic System Treaty Copy Periods/
Generations .
2. Enter the required data and choose Execute.
3. The system checks whether it has to create a new period or whether data is to be copied to an existing
period.
4. The system copies the data. This includes sections, partners involved, and the lower levels, as well as the
external references.
Note the following: The system changes the status of the target period to the highest existing status and
sets the Posting Not Allowed and Not Canceled checkboxes. The status is assigned the number “999
COPY” (predefined in Customizing); you must not change this status as it is entered to prevent potential
data inconsistencies (in the treaty type, for example). The system does not check the successor statuses
at treaty period level here. For more information, see Treaty Period [page 211].
Result
The system copies the treaty period. It displays a log listing all the copied objects.
5.1.3.5.3 Copying Treaty Sections
Prerequisites

● The target period exists.
● The source and target section have different section numbers.

Context
You use this procedure to copy the dependent entities within a treaty from one treaty section to another.
Procedure
1. In the FS-RI role menu, choose FS-RI Reinsurance Basic System Treaty Copy Treaty Sections .
2. Enter the required data and choose .

3. The system copies the section. It copies the external references as well only if you copy the section to
another period.
Results
The system copies a treaty section. It displays a log listing all the copied objects.
5.1.3.5.4 Copying Treaty Involvements
Prerequisites

● The target period exists.
● The source and target involvement have different involvement numbers.
Context
You use this procedure to copy the dependent entities within a treaty from one treaty involvement to another.
Procedure
1. In the FS-RI role menu, choose FS-RI Reinsurance Basic System Treaty Copy Involvement .

2. Enter the required data and choose .
3. The system copies the involvement. It copies the external references as well only if you copy the
involvement to another period. The system changes the status of the target period to the highest existing
status and sets the Posting Not Allowed and Not Canceled checkboxes. The status is assigned the number
“999 COPY” (predefined in Customizing); you must not change this status as it is entered to prevent
potential data inconsistencies.
Results
The system copies a treaty involvement. It displays a log listing all the copied objects.
5.1.3.6 Treaty Printout
Use
You use transaction /MSG/R_VTG_DRUCK to print a treaty.
You can use this function to print extracts from treaties, entire treaties, or several treaties at the same time.
Features
Selection Screen: Selecting the Treaty Data to Be Printed
You can select the treaty data to be printed by choosing Options and marking the relevant data in the column
PrSt (print status). If you do not select any data, the entire treaty is printed. The column DbSt indicates the
double-click status.
You can make more detailed selections for screens after and including screen number 2001. To do this, activate
the checkbox for the screen and branch to the detail view by double-clicking the title of the screen.
Print Attributes
Under print attributes, you indicate whether you want to print using the default settings (Without Dialog), or
whether you want to enter settings before printing (With Dialog), as well as the number of copies.
Output
If you have selected a period in the detail view for periods under Options, the data is printed only. If you have
not selected a specific period, the data is displayed on the screen or printed.

Activities
You can print a treaty in the following ways:
● Calling transaction /MSG/R_VTG_DRUCK

● Printing the treaty or period from the treaty:
1. Open a treaty in display or change mode.
2. Choose Extras Display Treaty or Display Period. The system prepares the data for printing.
3. To start printing, or schedule this for a later date, choose Extras Messages .
4. Save the treaty.
 Caution
The treaty is printed or scheduled for printing only after it has been saved.
For more information about message control, see the documentation for SAP standard functions.
Example
Treaty XY has two periods (01/01/04 and 01/01/05) and three sections (1, 2, and 3). Both periods contain all
three sections. You want to print the data for the broker in the period 01/01/04 and the data for section 3 in the
period 01/01/05.
You do this as follows:
1. Call transaction /MSG/R_VTG_DRUCK.

2. Enter the treaty number XY and choose the Options pushbutton.
3. A dialog box appears. Choose Deselect. The checkbox in the column PrSt is “deselected” in each row.
4. Select the checkbox PrSt in the row “Broker (2001)”. When you double-click the Tab Title field for this row,
a second dialog box appears.
5. Deactivate all periods except “01/01/04” and choose to return to the previous table.
6. Select the checkbox PrSt in the row “Sections (2003)”. When you double-click the Tab Title field for this
column, a second dialog box appears.
7. Deactivate all fields except for period “01/01/05” and section “3” and choose to return to the previous
table.
8. Choose Enter to return to the main screen and choose to print the data.
Alternative Print Program
In addition to the above, the FS-RI system offers an alternative print program for treaties.
You call this program as follows:
1. Switch to the message view by choosing Extras Messages .

2. Then choose Back.
3. Choose the action profile for printing the treaty (/MSG/VTG).
4. On the next screen, activate the message for printing the treaty and execute the action.

 Caution
The alternative print program uses its own forms. This means that a change made to the print form affects
only printing using one of these programs.
5.1.3.7 Mergers and Acquisitions
Use
The transfer group is a tool that you can use to process each portfolio transfer individually.
In the transaction Edit Transfer Group you can define the portfolio (PTF) to be transferred.
There are two different ways of doing this.
1. You can enter a source and target company, and define a Period From date, in the header data of a transfer
group. You can also enter a Period To date (though this is optional). If you do so, this specifies the latest
period start date used by the system for further processing.
The system then generates a proposal list of the treaties to be commuted.
Finally, you can adjust the in-force business from the transfer group. The FS-RI system creates new
involvements and participations in the affected treaties.
2. Alternatively, you can create pairs in the detailed data of the transfer group:
○ Source treaty and target treaty
○ Source section and target section
○ Source share and target share
You must have already created or changed the target treaties, target sections, or target shares. If the target
objects have been created accordingly, you can also use this method for partial transfers.
 Note
You can execute both procedures across company codes.
A transfer group can contain multiple source and target pairs. You can simulate and reset a transfer.
Every transfer group is uniquely identified by the transfer group number and can also have a user-defined
name.
The transfer group number corresponds to a number range object in the system.
Prerequisites
Before you use transfer groups, in Customizing for FS-RI Reinsurance under Basic System Basic Settings
Number Ranges Transfer Group you have to specify the number range in which the transfer group numbers
are to be assigned.

Features
The following combinations are permitted for transfers, with certain restrictions.
Source Target Condition
Assumed business Reinsurer Reinsurer To be able to create this

model, you have to create a
new treaty for the target.
Assumed business Cedent Cedent To be able to create this

model, you have to create a
new treaty for the target.
Ceded business Reinsurer Reinsurer
Ceded business Reinsurer Not placed To be able to create this

model, leave the target in
volvement empty.
If the cedent for a treaty is switched, the cedent is also entered in the transfer group as an involvement.
 Caution
The transfer of one cedent to another is not supported in ceded business because this presupposes that
the underlying portfolio (the in-force business of the primary insurer or the active underwritten business)
has changed owner. A large number of transfer measures would then be required in the treaty portfolio. For
this reason, the ceded business cannot be transferred; instead the primary insurance portfolio or the
transfer portfolio must be transferred.
If you want to transfer only specific subportfolios, from only one class of business for example, you have to
create and configure the target object (target treaty or section) accordingly. In this case, you must enter the
source and target object pairs manually in the transfer group.
If you want the system to support the adjustment of in-force business, you can enter the source and target
company, and define a Period From date, in the header data of a transfer group. You also have the option of
entering a Period To date. If you do so, this specifies the latest period start date used by the system for further
processing.
When you then execute the Generate Proposal List function, the system lists in the detailed data of the transfer
group all treaties in which the business partner of the source company is saved in the role of cedent or
reinsurer in at least one period whose start date is the same or after the date in the header data.
The following table shows which constellations are considered.

Source Target Company Appears in Pro Comments
posal List
Company Role Treaty Direction
External company Cedent Assumed External company Yes
External company Cedent Assumed Owner company No The transfer is not

supported be
cause a previously
underwritten port
folio was transfer
red to the compa
ny’s in-force busi
ness for this con
stellation. This
means that this
transfer must be
handled using a
different treaty.
External company Reinsurer Assumed Owner company or No External reinsurers

external company are used in as
sumed treaties for
information pur
poses only; data is
not posted for
these reinsurers.
For this reason,
such participa
tions cannot be
part of a portfolio
transfer.
Owner company Reinsurer Assumed Owner company Yes
Owner company Reinsurer Assumed External company No The transfer is not

supported be
cause this constel
lation is a portfolio
withdrawal portfo
lio withdrawal.
External company Cedent Ceded Owner company or No External compa

external company nies do not occur
in ceded treaties
as cedents.

Source Target Company Appears in Pro Comments
posal List
Company Role Treaty Direction
External company Reinsurer Ceded Owner company Yes This is a carryfor

ward in the reten
tion.
External company Yes
Owner company Cedent Ceded Owner company or No The owner of the

external company underlying busi
ness has changed.
This means that
the transferred as
sumed business or
the underwritten
business must be
transferred and
not the (retro) ces
sion.
Owner company Reinsurer Ceded Owner company or Yes

external company
Deleted treaties and pseudo assumed treaties and portfolio treaties are not selected. You can use Customizing
settings to control whether treaties used in Risk Manager are also selected.
The system also filters out periods that have a status that does not allow posting.
If you have defined a source and target company in the header, you cannot add data or change the existing data
manually in the detailed view. However, you can delete individual rows after the proposal list has been
generated if these rows do not need to be processed further.
After you have generated the proposal list, you can execute the Adjust In-Force Business function to adjust the
treaties. New involvements and, if applicable, participations are written to the treaties in the background. The
status in the periods is not changed.
However, you can define statuses and change reasons for the new participations in Customizing. These are
then assigned when you generate the participations.
When the in-force business has been adjusted, you can trigger the processing of the account directly using the
Execute Transfer function.
You can execute these functions for the individual rows of a transfer group or for all the rows of a transfer group
by selecting the relevant rows.
The global conditions [page 251] are used to determine which postings have to be transferred and, where
applicable, cleared or calculated in the source treaties, sections, and shares (for example, PTF withdrawal). The
global conditions are stored in the transfer group header separately for the source and target.
A central validity date is entered in the transfer group header. This specifies the key date on which the different
sources are to be transferred to the corresponding target. Posting must be allowed to these target

participations on this key date at the latest. The system ignores any existing alternative validity dates for
participations in the treaties. You can also enter a field bundle for flexible summarization [page 174] here.
The source participations can be closed after the data has been transferred without errors. These
participations are then assigned a status that does not allow posting. You define this status in Customizing. You
can close the source participation using the Close Source function. Once the source participations have been
closed you cannot reset the transfer.
Validation Checks
Validation checks are provided to ensure that the correct data is entered when transfer groups are defined.
The source and target must not be identical and must have the same treaty direction and treaty class.
 Example
Source Treaty Source Sec Source Share Target Treaty Target Section Target Share Transfer Possi
tion ble
1 1 1 1 1 2 Yes
1 1 1 1 1 1 No
1 1 1 1 1 2 No
1 1 1 1 1 2
1 1 1 2 1 No
1 1 1 2 1 1
1 1 1 2 1 1 Yes
1 1 1 2 2 1
Activities
To edit transfer groups, select Edit Transfer Group (transaction /MSG/R_TXGRP02).
To display transfer groups, select Display Transfer Group (transaction /MSG/R_TXGRP03).
To define transfer groups for a portfolio transfer:
1. Define the portfolio to be transferred. If necessary, or if you want to define the transfer group manually,
create new treaties or new involvements and participations in existing treaties for the target objects.
2. In Customizing for Basic System under Accounting Entry Code Edit Calculation Bases and Rules ,
define the calculation bases required for the posting data to be transferred.
3. Under Treaty -> Templates -> Global Conditions (category: TXGRP, see Global Conditions), define the
conditions required for the source and target objects.
4. Define the transfer groups under Edit Transfer Group. Enter either the source and target object pairs or the
source and target company and the period-from date in the transfer group header for which the same

conditions apply. The conditions are stored as a global condition for source and target in the transfer group
header (transaction /MSG/R_TXGRP02).
5. If you have entered the source and target company and the period-from date in the transfer group header,
execute the Generate Proposal List function and then the Adjust In-Force Business function.
6. Run the Execute Transfer background job.
7. If the portfolio transfer has been executed without errors, set the commuted shares to a status that does
not allow posting using the Close Source function.
5.1.3.7.1 Mergers and Acquisitions: Automatic Adjustment

of In-Force Business
Use
You can use the automatic adjustment of in-force business in different constellations. However, there are some
restrictions.
Features
The following table shows the constellations and restrictions.

Source Target Company Adjustment of In-Force Business in
Treaty
Company Role Treaty Direction With Use in RM Without Use in

RM
External company Cedent Assumed External company AUTOMATIC AUTOMATIC
1. Automatic 1. Automatic
generation of generation of
target involve target involve
ment in treaty ment in treaty
2. Automatic 2. Automatic
generation of generation of
target partici target partici
pation(s) in pation(s) in
treaty treaty
3. Transfer of 3. Transfer of
conditions (if conditions (if
requested) requested)
4. Automatic ad
justment of
cedent partic
ipation
Owner company Reinsurer Assumed Owner company Adjustment must Adjustment must
be made manually; be made manually;
this is because a this is because a
completely new completely new
treaty is required treaty is required
due to a change of due to a change of
company code (in company code (in
cluding cession cluding cession
rule if applicable) rule if applicable)
External company Reinsurer Ceded Owner company Generally supports Generally supports
exceptions if these exceptions if these
External company relate to transfers relate to transfers
to deductibles and to deductibles and
other cedents (co- other cedents (co-
cedents) exist cedents) exist
Owner company Reinsurer Ceded Owner company or MANUAL MANUAL if a par

external company ticipating treaty
Manual target cre
entered for source
ation in Basic Sys
company (manual
tem and Risk Man
creation of new
ager and manual
participating
transfer group re
treaty probably re
quired because
quired)

Source Target Company Adjustment of In-Force Business in
Treaty
Company Role Treaty Direction With Use in RM Without Use in

RM
new treaty needed; AUTOMATIC in all

adjustment must other cases:
be made manually 1. Automatic gen
based on connect eration of target
ing participations, involvement in
both in Basic Sys treaty; 2. Auto
tem and Risk Man matic generation/
ager. adjustment of
source and target
participation(s) in
treaty; 3. Transfer
of conditions (if re
quested).
In addition to the source and target company, you can also define in the header data whether conditions or
broker data is also copied when in-force business is adjusted.
When you select Transfer Conditions, the system also copies the share-specific conditions (result-independent,
result-dependent fund agreements) for the new involvement. This means that the conditions that exist for the
source participation are copied and saved with the involvement number of the target share.
If a compensation rule exists for a result-independent condition this rule is not copied. In this case, it may be
necessary to postprocess the data manually.
When you select Transfer Broker, the system creates and saves the broker link when it generates the target
involvement.
The participations are determined according to the broker participations.
5.1.3.7.2 Mergers and Acquisitions: Functions and Status
Use
Different pushbuttons are available during the different processing stages for a transfer group.

Features
Name Description of Function
Generate Proposal List Creates proposal list
Adjust In-Force Business Adjusts treaties (Basic System) and policies (Risk Manager)
Execute Transfer Branches to the background job for transfer groups
Undo Transfer Resets the background job for transfer groups
Close Source Closes the source
Each of these functions assigns a status to each detailed row of a transfer group to indicate the stage in the
process.
The following table shows the statuses used.
Status Short Text Description
Created manually MAN Denotes a transfer group that was cre

ated manually
Proposal generated TTYS Denotes a row in the transfer group cre

ated using the Generate Proposal func
tion
To be adjusted manually MAC Denotes a row in the transfer group that

cannot be processed automatically
Problem adjusting in-force business PTFCE Denotes a row in the transfer group for
which there were problems during proc
essing
In-force business adjusted PTFC Denotes a row in the transfer group that
was processed without errors
Transferred TX Denotes a row in the transfer group

which has already been transferred
Source closed CL Denotes a row in the transfer group

whose source was closed
5.1.3.7.3 Mergers and Acquisitions: Procedure
The transfer groups are calculated by the Execute Transfer background job.

The system derives a treaty calculation rule (TCR) from the source and target pair. This treaty calculation rule
is used in the conditions of the global condition [page 251].
When transfer groups are defined, the system always assumes that a transfer is taking place from an explicit
cedent or reinsurer to another cedent or reinsurer or that the retention is being transferred. This means that
the transfer postings are always made at share level. Quota share or NP liability data is therefore not included.
Moreover, no signed lines are calculated.
Conditions
The source conditions are applied only to the posting data that was selected for transfer and that could be
transferred based on the structural characteristics and the dates and times of the target treaty and section. For
more information, see the example [page 323].
Validity
The validity of each target participation is defined using the central validity start date in the transfer group.
However, when the transfer group is processed there may be change entries as the result of changes to the
signed line. These are normally processed by the Adjustment After Changing the Signed Line background job.
To stop this adjustment report from generating additional accounts, which can lead to incorrect results, when
the system processes the portfolio transfer it marks as processed any signed line changes with a validity date
on or after the transfer date.
Selection Period
You use the selection period entered in the global conditions [page 251] to define whether a movement type
has to be transferred “incrementally” (INCRE), on a “year-to-date” (YTD) basis (for reserves, for example), or
on an “inception-to-date” (ITD) basis (for funds, for example). This definition is required so that the correct
statuses for reserves and funds can be generated in the target object (see also "Global Conditions").
The Incremental value can be used for all liquid items without funds. All the accounts whose accounting period
start date is on or after the validity start date of the transfer group are processed (transferred) on the basis of
this value.
Non-liquid items entered for a condition and with the selection period “year-to-date” are processed as follows:
● Non-liquid balance sheet items: Only postings that lie in the accounting year are processed. The
accounting year is determined based on the FI posting date used.
● Non-liquid statistical items: Only postings that lie in the accounting year are processed. The accounting
year is determined based on the validity start date of the participation (in this case, the validity start date
from the transfer group).
Postings from accounts whose accounting period start date is on or after the start date of the target share are
processed as Incremental values.

If the value “inception-to-date” is used as a selection period for a condition, when it processes this condition
the system selects and processes all the postings for this treaty period independent of the accounting year.
The “inception-to-date” logic is required for fund postings, for example. The total funds held can be determined
correctly for the target only if all the retained and released funds are included at the start of the treaty period.
Selection Conditions
The following table shows the selection conditions relating to the individual selection periods in combination
with the entry code types to be processed.
Selection Pe ITD YTD INCRE

riod
Without Inte Without Integrated INCRE Individually or as Part of ITD or YTD
grated INCRE Method
Method
Entry code Non-reserve Statistical re Balance sheet Non-reserve Statistical re Balance sheet
serve reserve serve reserve
Lower limit None Accounting pe FI posting date Accounting pe Accounting pe FI posting date
riod start date riod start date riod start date
>= >
>= >= >=
start date of the FI posting date
start date of the financial year of validity start validity start of transfer
account year of the source date of target date of target background job
the source treaty in which participation participation
treaty in which the FI posting
the “validity date of the
start date of the transfer back
target share is ground job falls
minus 1 day”
Upper limit Accounting pe Accounting pe FI posting date FI posting date FI posting date FI posting date
riod start date riod start date
<= <= <= <=
< <
FI posting date FI posting date FI posting date FI posting date
validity start validity start of transfer of transfer of transfer of transfer
date of target date of target background job background job background job background job
participation participation
FI posting date FI posting date
<= <=
FI posting date FI posting date

of transfer of transfer
background job background job

Selection Pe ITD YTD INCRE
riod
Without Inte Without Integrated INCRE Individually or as Part of ITD or YTD
grated INCRE Method
Method
Entry code Non-reserve Statistical re Balance sheet Non-reserve Statistical re Balance sheet
serve reserve serve reserve
Handling of re The system The system The system Upper and
serves also processes also processes does not proc lower limits re
reserves origi reserves origi ess reserves sult in an empty
nating from the nating from the originating from set of data.
reserves carried reserves carried the reserves
forward. forward. carried forward.
 Note
ITD and YTD always contain the INCRE method. The table shows the process for a simple ITD and YTD,
without an integrated INCRE method.
The date that is referred to in the “year-to-date” and “inception-to-date” is:
● The validity start date of the target participation (in the case of statistical entry codes)
● The FI posting date from the Execute PTF Transfer background job (in the case of balance sheet entry
codes)
You can control whether treaties used in Risk Manager are also processed. If you have activated the use of a
treaty in Risk Manager, then the system selects and processes Risk Manager accounts in the same way as
described above. For more information, see Reserve Postings in Risk Manager [page 149]). You find this in
Customizing for FS-RI Reinsurance under Basic System Treaty Transfer Group Basic Settings for
Transfer Group .
5.1.3.7.4 Mergers and Acquisitions: Fund Agreements
If fund conditions have been entered for the target share of a portfolio transfer, then you have to make sure that
any subsequent fund calculations are postprocessed correctly after the portfolio has been transferred.
 Example
If a portfolio transfer becomes valid in the middle of a year (for example, on July 1, or Q3) but the total
funds held are only adjusted at year-end (for example, funds are retained or released at year-end from the
closing balance of the previous year), then manual adjustments may be necessary because the regular
intervals have been interrupted.
This interruption means that the function for calculating funds cannot correctly determine the total
number of funds held based on the posting made in the third quarter.

5.1.3.7.5 Mergers and Acquisitions: Determination of
Accounting Periods
The accounting period of the accounts created by a transfer is determined based on the selection period and
the entry code type.
The following table provides an overview.
Accounting Period of Generated Accounts with Condition Category FIL,

TRAN, and CLRD
Accounting Period of Generated Account
ITD YTD INCRE
(Simple ITD Without IN (Simple YTD Without IN (INCRE Only or as Part of
CRE) CRE) ITD or YTD)
Balance sheet reserves Not permitted Accounting year and ac Permitted but the result is an
counting period are calcu empty set of data
lated from the FI posting date
of the Execute PTF Transfer
background job, taking into
consideration the accounting
frequency and the account
ing year end date of the tar
get treaty.
Where:
accounting period start date
>=
validity start date of target

participation

ITD YTD INCRE
(Simple ITD Without IN (Simple YTD Without IN (INCRE Only or as Part of
CRE) CRE) ITD or YTD)
Statistical reserves Not permitted Accounting year and ac Accounting year and ac
counting period are calcu counting period are calcu
lated from the validity period lated from the accounting
start date of the target par period end date of the source
ticipation, taking into consid account, taking into consid
eration the accounting fre eration the accounting fre
quency and the accounting quency and the accounting
year end date of the target year end date of the target
treaty. treaty.
Where: Where: accounting period

start date
>=
>=
participation
participation
Non-reserves Accounting year and ac Not permitted

counting period are calcu
lated from the validity period
start date of the target par
ticipation, taking into consid
eration the accounting fre
quency and the accounting
year end date of the target
treaty.
Where:
>=

participation

Accounting Period of Generated Accounts with Condition Category PTFE and
PTFW
Non-reserves Statistical reserves Balance sheet reserves
PTFE Accounting year and accounting period are calculated from Note: The calculation of PTF
the validity period start date of the target participation, tak withdrawal and PTF entry is
ing into consideration the accounting frequency and the ac not supported in FS-RI for
counting year end date of the target treaty. balance sheet reserves. This
is not however prevented by
If the accounting period start date lies before the validity
validation checks. You are re
start date of the target participation as a result of the rule
sponsible for the use of this
above, then the accounting period start date must be set to
function.
the validity start date of the target participation.
PTFW Accounting year and accounting period are calculated from

the validity start date of the target participation minus 1 day,
taking into consideration the accounting frequency and the
accounting year end date of the source treaty.
If the accounting period end date is on or after the validity

start date of the target participation as a result of the rule
above, then the accounting period end date must be set to
the validity period start date of the target participation mi
nus 1 day.
5.1.3.7.6 Mergers and Acquisitions: Portfolio Entries and

Withdrawals
You can calculate portfolio entries and withdrawals independent of the treaty mode.
Portfolio entries in the target share are calculated based on postings that exist in the source. The posting data
is classified on the basis of the validity start date of the transfer group.
If the portfolio entry or withdrawal is being calculated on the basis of non-liquid items, the system selects all
the postings from the start of the accounting year, where the accounting year is the validity period start date of
the target share for the source treaty minus 1 day (“year-to-date”).
If the portfolio entry or withdrawal is being calculated on the basis of liquid items, the system selects all the
postings that exist for the source share (inception-to-date).
If the portfolio entry or withdrawal is being calculated on the basis of liquid items, the system selects all the
postings that lie after the transfer key date (“incremental”).
 Note
To avoid possible exchange rate differences during the portfolio transfer, you can use the Orig. ER checkbox
(“Use Original Exchange Rate for Incremental Postings”) in Customizing under FS-RI Reinsurance

Basic System Treaty Transfer Group Basic Settings for Transfer Group to indicate that incremental
postings are written off using the original exchange rate and are posted for the new business partner.
“Year-to-date” and “inception-to-date” postings are always posted for the new business partner using the
exchange rate that is currently valid.
When it generates the accounts for portfolio entry premiums, the system calculates the occurrence year and
the occurrence date as follows:
● Occurrence year = year of the accounting period start date of the account
● Occurrence date = day and month of the accounting period start date of the account
The accounting periods for portfolio entry accounts or portfolio withdrawal accounts are calculated as follows:
Portfolio entry:
● Accounting period start date: valid-from date of the target participation

● Accounting period end date: calculated based on accounting period start date, taking into consideration
the accounting frequency
Portfolio withdrawal:
● Accounting period end date: valid-from date of the target participation minus 1 day
● Accounting period start date: calculated based on accounting period end date, taking into consideration
the accounting frequency
 Note
The date of the target participation is the same as the validity start date of the transfer group.
5.1.3.7.7 Mergers and Acquisitions: Transfer of Loss

Postings
Provided you have selected the Loss Assignment Check checkbox in Customizing (Edit Defaults for
Accounting), when the system processes postings with loss numbers during a portfolio transfer it links the new
target object with the relevant loss.
If a loss has postings that have to be transferred but this loss has a locked status then these postings are not
processed.
In some cases it may be that specific single losses have to be excluded from a portfolio transfer. The structure
of these losses then remains the same as in the original share. You specify the exclusion of a loss from a
portfolio transfer in its status by selecting the “Do Not Transfer” checkbox in Customizing for Basic System
under Loss Edit Loss Statuses .
If you are transferring loss postings for non-proportional treaties then you must make sure that postings that
occur during non-proportional calculation (such as below deductible, in excess of liability, AAD, AAL) are also
transferred. This ensures that the FGU account can still be executed correctly in the target share.
In this regard, you must also make sure that any effective payments are also transferred or that transfer
postings are made to a statistical entry code. This ensures that you can calculate the liability used and that
payments are not included in the balance sheet again.

Life-Specific Postings
Life-specific entry codes (such as Number of Life Treaties) are transferred with the selection period “inception-
to-date”. This is necessary to ensure that the system finds and transfers the entire data. Unlike reserves, there
are no balances for this data in the current accounting year based on carryforwards.
5.1.3.7.8 Example: Transfer Group
In addition to the posting data that is transferred from the source treaty, section, and share to the target treaty,
section, and share based on the global condition, the conditions that apply to the source treaty, section, and
share must also be applied to the correct posting data. This means that the source conditions are applied only
to the posting data that was selected for transfer and that could be transferred based on the structural
characteristics (areas, classes of business) and the dates and times (such as terms and accounting modes) of
the target treaty and section.
Source Treaty 1010
Term January 1, 2009 – December 31, 2009
Section 1
Class of business F – fire
FCL – fire consequential loss
BT – burglary and theft
Area D – Germany
A – Austria
CH – Switzerland
Target Treaty 1020
Term January 1, 2009 – December 31, 2009
Section 1
Class of business F – fire
FCL – fire consequential loss

Area D – Germany
A – Austria
Existing Posting Data in Source Treaty
Entry Code Class of Business Area Amount
Loss reserve F D 20,000
Loss reserve F A 15,000
Loss reserve F CH 12,000
Loss reserve FCL D 10,000
Loss reserve FCL A 8,000
Loss reserve FCL CH 7,000
Loss reserve BT D 2,200
Loss reserve BT A 900
Loss reserve BT CH 1,100
Transfer Group
Global condition for target Filter 100% loss reserve
Global condition for source Clear -100% loss reserve (clear reserve)
(source and target as described above)
Data Posted to Target After Executing TXGRP
Loss reserve F D 20,000
Loss reserve F A 15,000

Loss reserve FCL D 10,000
Loss reserve FCL A 8,000
Postings Generated in Source After Executing TXGRP
Loss reserve F D -20,000
Loss reserve F A -15,000
Loss reserve FCL D -10,000
Loss reserve FCL A -8,000
5.1.3.8 Mapping of Retrocession
The FS-RI system offers the user a number of options for creating relationships between treaties. You use these
functions mainly to link your assumed business to your ceded business.
For more information about treaty groups, see Treaty Groups [page 343].
5.1.3.8.1 Section-Based Retrocession
Use
You link treaties in this way when you want to retrocede business from an assumed treaty or treaty section to a
ceded treaty or treaty section.
This type of retrocession can also be used for the assumed business side of a connecting treaty [page 199].
Integration
When you link treaties, the system creates the ceded accounts for the retrocession treaty for the assumed
accounts for the assumed treaty or for the ceded share of the connecting treaty. These accounts have the
status “Open”.

Prerequisites
● You have created an assumed treaty or connecting treaty and a ceded treaty.
● The ceded treaty has the structural characteristics of the treaty or section it is to retrocede. For more
information, see “Features”.
● The periods of the retrocession treaty to be assigned to the assumed treaty overlap with the assumed
treaty period. The overlap can cover any date or time period.
● You are authorized to edit retrocession data. You make this setting in Customizing, where you can define
whether a person is authorized to edit the assumed treaty, the retrocession treaty, or both.
● You have set the Specific Retrocession Treaty checkbox at treaty header level in the ceded treaty.
● You have set the Specific Retrocession Allowed checkbox at treaty header level in the assumed treaty.
● You have set the Specific Retrocession Allowed checkbox at treaty header level in the connecting treaty.
● The structure of the accounting units of the retrocession treaty is contained within the structure of the
accounting units of the assumed treaty or the structure of the connecting treaty. This means that the
attributes and values assigned to the ceded accounting unit are also contained in those assigned to the
assumed accounting unit. However, the assumed accounting unit may have a greater level of detail and
contain a larger number of attributes. The validity period of the assumed accounting unit must overlap with
the validity period of the ceded accounting unit. The overlap can cover any date or time period.
● In Customizing for Basic System under Default Values Edit Defaults for Treaties , you can specify
whether these attributes and values are assigned in the assumed treaty only or in the retrocession treaty
only.
Features
Partial Overlap
The system also accepts assignments for retrocession sections that do not cover the assumed section
structurally or temporally (100%).
The system checks whether an account is actually covered by the retrocession section only when it is
transferred to the background job.
Open Retrocession Data
When you assign an assumed treaty to a retrocession treaty, the system checks what type of coverage exists
between the assumed and the retroceded business side based on the partial overlap category entered.
When you release inward accounts, the system checks whether the assumed treaty section for which postings
exist is assigned to a retrocession treaty.
If this is the case, the system creates open retrocession accounts (open retrocession data). In doing so, the
system creates a flag for each possible combination of sections containing retrocession data, if you have not
specified a retrocession section when assigning the retrocession treaty. For example, if there are three
retrocession sections, the system creates three flags.
You can see these flagged accounts in the assumed treaty on the Open Retrocession Data tab page in the treaty
period. The same applies to the retrocession for an assumed share in a connecting treaty. The open
retrocession data can be displayed in the connecting treaty.
When it transfers accounts to the retrocession side in a background job, the system determines which of these
flagged accounts are relevant for transfer and creates a retrocession account for these. These accounts, and

those not relevant for transfer, are marked as “processed” and are no longer displayed on the Open
Retrocession Data tab page.
Assignment Rules
When you make assignments in retrocession and assumed treaties, you can include either individual sections
or all sections in a period. If you do not enter any section, the assignment applies to an entire treaty.
In both cases, the sum of the values for structural characteristics in the assumed treaty must be contained in
the sum of the values for structural characteristics in the ceded treaty. If the overall structure of the assumed
treaty is distributed to sections differently to that of the ceded treaty, the system uses the structural
characteristics of the posting to determine the section in the ceded treaty to which to post the ceded posting.
 Example
In the period 2005, you assign section 1 of assumed treaty A (TtyASec1) to ceded treaty B (TtyB, no section
or period data).
You assign the area “BeNeLux” to TtyASec1.
TtyB contains three sections: Sec1 has the area “Belgium”, Sec2 has the area “Netherlands”, and Sec3 has
the area “Luxembourg”.
All other structural characteristics of the sections are the same.
Each time a posting is made to TtyASec1, the system checks the area to which the posting is assigned and
creates a retrocession posting in the corresponding section of TtyB. In this way, the various postings
contained in one and the same account can be assigned differently.
Structural Characteristics for the Retrocession Account
In the structural characteristics of the ceded treaty, you specify whether the system should use the original
structural characteristics in the account or the main structural characteristics of the retrocession treaty.
Activities
Assignment in the Assumed Treaty
On the Retrocession tab page at period level, you enter the sections you want to retrocede, the relevant shares,
and the treaties or treaty sections you want to use.
If you do not enter a section, the system considers all sections in the treaty period.
Assignment in the Retrocession Treaty
In the ceded treaty on the Assumed Business tab page at period level, you enter the treaties and sections from
the assumed period you want to retrocede, and the relevant share from the section.
If you do not enter a section, the system considers all sections in the treaty.

5.1.3.8.2 Share-Based Retrocession
Use
You can retrocede treaties based on shares. In other words, a share of an assumed treaty is entered in a ceded
treaty. As with partners involved, the ceded treaty appears as treaty involvement.
You can use this procedure to retrocede treaties between different company codes.
Procedure
1. Switch to the Participations tab page at treaty period level.

2. Enter the treaty to be retroceded as a ceded participating treaty.
For more information about participating treaties, see Participating Treaty [page 328].
5.1.3.8.2.1 Participating Treaty
Definition
A participating treaty is a treaty created in the system that takes on a share of another treaty. As such, it fulfils
the same role as a partner involved.
Use
You use a participating treaty to link two treaties together in a ceded and reinsured treaty based on the treaty
share.
Ceded participating treaties are one way of mapping retrocessions in the FS-RI system.
Assumed participating treaties represent independent shares in an FS-RI treaty and can be used to map
distributed business processes.
Prerequisites
The following prerequisites apply for using a treaty as a participating treaty in a master treaty:
● The partner involved in the participating treaty has the role “Reinsurer” and is “Processable”.
● You can use the treaty once only per period.
● The treaty has the same structure as the master treaty. For example:
○ Same section numbers (the participating treaty may, however, have more sections).
○ The classes of business, areas, business types, currencies, and lines of business in the master treaty
are included in the participating treaty. For ceded participating treaties, the line of business must be

included only if lines of business have been defined as a structural criterion in Customizing for Basic
System (under Default Values Edit Defaults for Accounting ).
○ The premium mode and loss mode are the same in all sections.
● The treaty does not contain risk carriers [page 210].
● If you set the Use in RM checkbox, the treaty must have a different owner company code to the master
treaty. In other words, the participating treaty can be only an assumed treaty for a different company code.
● The period start date of the section of the master treaty lies within a period of the participating treaty.
● The master treaty is not a participating treaty in the participating treaty chosen.
Criteria for Ceded Participating Treaties
● The master treaty and participating treaty are in the same company code.
● The participating treaty is part of the treaty owner's retention. As a result, its participations may not exceed
the retention of the owner company.
● You are not allowed to enter a partner involved.
Criteria for Assumed Participating Treaties
● The master treaty and participating treaty belong to different company codes.
● The master treaty is a ceded treaty.
● The participating treaty contains at least one cedent from the master treaty.
● You have defined the partner involved. This is the owner company of the participating treaty.
5.1.3.8.3 Treaty Calculation Rules
Definition
Treaty calculation rules are filter criteria (rules) that you can use to select posting data from a group of treaties
and copy it to a specified target treaty (or target groups) (see also “Structure” for the special features of “plus”
and “minus” ranks).
This posting data is selected and calculated using a number of rules that work together. These rules consist of
the contents of structural treaty elements and of other treaty data. There are 35 criteria in total. The criteria are
linked by relational operators to logical expressions. The priority of a rule is determined by its rank. The
character of the rule is determined by its usage type (for example, plus or minus).
Treaty calculation rules create relationships between treaties or between treaties and treaty portfolios.
Use
When you copy posting data to the target treaty, you can handle entry codes in the following ways:
● Select: You can select which entry codes are posted in the target treaty.
● Convert: If entry codes have different numbers in the source and target treaty, you can convert the entry
code number in the source treaty to the correct number in the target treaty.
● Proportional use: You can post an entry code in the source treaty to the target treaty proportionally.

Calculation
You calculate the results for the treaty calculation rules using the background job Process Treaty Calculation
Rules [page 531] (/MSG/R_ABR_VTGRECHENREGELN). You call this background job by choosing Process Treaty
Calculation Rules in Schedule Manager (transaction SCMA).
Method
The system finds the processing rule for the first target treaty in the treaty calculation rule or creates an
internal description of the selection criteria relevant for the target treaty. It then uses these criteria to find the
corresponding data for each +/- rank (see “Structure”). To do this, the system starts a separate read operation
for each +/- rank.
Time Limit
When you execute a treaty calculation rule for the first time, the system processes the data without any time
restriction.
When you execute subsequent treaty calculation rules, the time in which the data must be processed is
determined by the most recent processing time entered for the calculation rule: The system processes only
posting data that was released after this time.
This means that the treaty calculation rules do not allow the creation of accounts in the target treaty for
accounting periods that fall before the period that was last selected.
Treaty Calculation Rules for Connecting Treaties (Assumed/Ceded Checkbox)
Connecting treaties contain both inward and outward accounts; you can select these by setting the “Assumed/
Ceded” checkbox.
Structure
A treaty calculation rule consists of a group of policy sections with different ranks. You can configure one of four
different usage types (individual rules) for each rank:
1. “Plus” rank (n-fold possible): initial data, use with positive sign
2. “Minus” rank (n-fold possible): initial data, use with negative sign
3. “Equal To” rank (n-fold possible): hit list or interim result
4. “Through Posting” rank (n-fold possible): in non-proportional target treaties, the system copies the initial
value from the source treaty. It does not perform any non-proportional calculations.
For plus and minus ranks, the effective dataset is always within the range defined by the target treaty, even if
their individual definitions go beyond this range. The description of an individual rank is compared only with the
dataset specified by the target treaty and never with the dataset for the other ranks.
A treaty calculation rule must have at least one “Plus” rank and one “Equal To” rank.
 Caution
Keep the number of ranks used to a minimum, since every plus or minus rank triggers its own reading
cycle, which reduces system performance.

More Information
Examples of Treaty Calculation Rules [page 334]
5.1.3.8.3.1 Editing of Treaty Calculation Rules
You can edit treaty calculation rules on several levels.
Level 0: Selection
On the initial screen, you can:
● Display all the treaty calculation rules that meet the selection criteria
● Select a treaty calculation rule to be displayed or edited
● Create a new treaty calculation rule
If you have selected more than one treaty calculation rule using certain search criteria, in the list of search
results you can choose two further options:
● Delete one or more treaty calculation rules

● Copy a treaty calculation rule
 Note
When you access the screen for selecting treaty calculation rules, the system checks whether you are
authorized to display, change, or create a treaty calculation rule.
If you have entered a role or competence in Customizing that is specified as a required entry field in the treaty
calculation rules, you must enter the person responsible in the header data. A treaty calculation rule may be
changed only by the persons entered in “Responsibilities”.
Level 1: Calculation Rule Items
At this level you define the individual items for the rule.
A unique rank is assigned to each item; this rank defines the order in which data is processed.
You must assign a freely definable and informative search criteria name (Search Criteria: Group Name) to each
item.
+ or – outbound quantity, plus/minus factor + or -
= target quantity, maximum expansion of outbound quantity

# transfer of posting data
The system weights all the entries included in a treaty calculation rule according to the specified percentage
and automatically multiplies these by the plus/minus factor as entered in the Usage Type field.
A treaty calculation rule must have at least one “Plus” rank and one “Equal To” rank.
You can also enter a global condition [page 251] at this level for the = rank and the # rank (transfer rank).
Special Features of the Ranks with Usage Categories + and –
If plus ranks are used for assumed business, a specific retrocession relating to this business can be processed
without being entered separately as a minus (-) rank. When you select the posting data, the system has already
automatically deducted the shares that have been retroceded. This means that this specific retrocession
cannot be deducted twice.
 Note
The system considers only the intersection of the inbound quantities with the outbound quantity of the
target treaty.
Special Features of the Ranks with Usage Type "Equal To" (Target Treaty/Target Rank)
 Caution
At selection option level, you can enter only the criteria "Treaty Number", "Section Number", or "Company
Code"; otherwise, when you save your entries, the system displays an error message.
A target rank can also define an interim result [page 333].
When you set the Split, Calculate, Release checkbox, the system splits, calculates, and releases the accounts
generated for an equal-to rank in the treaty calculation rules. These accounts are included in the results of the
next equal-to rank. Preliminary accounts cannot be released in simulated treaty calculation rules. However,
these accounts are included in the results of the next equal-to rank.
If you enter entry codes or calculation bases for the target section for application of a treaty calculation rule,
you must enter these as result-independent conditions in the target treaty.
If more than one company code is entered in the target treaty as co-cedent or as reinsurer, the system can also
transfer the posting data for these company codes. The following rules apply:
● If assumed business is defined as a plus or minus rank, the reinsurer assuming the business must appear
as a company code in the target treaty. You then need to enter the company codes as cedent or co-cedent
in the target treaty.
● If ceded business is entered in the plus or minus rank, the cedent must be assignable as the company code
in the target treaty.
Special Features for Section-Specific Retrocession (Specific Retro)
You can select the following options:
1. In plus and minus ranks, you can enter “specific retrocession” (SPEC_RETRO) as a selection option.
Result: The selection of source treaties is restricted. For example, you can select only a treaty with specific
retrocession assignment or exclude treaties with specific retrocession.
2. You can set the Specific Retrocession Treaty checkbox in a plus rank.

Result: You use this checkbox to control whether the deduction of specific retrocession is included in the
treaty calculation rules. If you select this checkbox and select source treaties, the system includes
retrocession treaties that are assigned to the assumed source treaties using specific retrocession
assignment. The corresponding retrocession accounts are offset against the original source accounts and
the specific retrocession amount is deducted.
Level 2: Selection Options
This level defines the selection options for an individual calculation rule item. You can choose from a total of 35
criteria, consisting of structural elements and other treaty data. You can combine these criteria with logical
expressions using operators (+/- Sign, Option, and so on). You are allowed to include the same criteria more
than once.
Customizing
Check whether structural authorizations have been used for the responsibilities that affect the criteria Role,
Partner (person responsible), Department Number, and Object ID. If so, in Customizing under Edit Defaults for
Treaty Calculation Rules you must enter a default value to control the responsibilities, such as “Responsible for
Treaty”. This means that the only criterion possible in the calculation rule is Object ID.
You can restrict the possible entries for the treaty numbers in Customizing by defining one or more roles or
competences, which are marked in the treaty as required data. The value set is then restricted to the treaties in
which the user is specified as the person responsible in the assigned roles or competences.
Similarly, you may only change an equal-to rank if you are entered as the person responsible in the treaty
specified for this rank in the role or competence defined in Customizing. Therefore, you may be authorized to
enter a treaty calculation rule but not to change the equal-to rank.
 Note
In plus and minus ranks, you can enter the Assumed/Ceded checkbox (EAKZ) as a selection option.
Unlike previous versions, the assumed/ceded checkbox replaces the use of the treaty category as a
required entry field in the plus and minus ranks.
Interpretation of Selection Criteria as Logical Expressions
If you enter the same criteria more than once (for example, several classes of business), the plus and minus
ranks are interpreted as OR links.
Different criteria (such as cedent and treaty number) are interpreted as AND links.
You can exclude each criterion by setting the +/- Sign field to “Excluding”.
For the year-based figures you can use the options <= and >=.
5.1.3.8.3.2 Interim Results in Treaty Calculation Rules
If you want to calculate and post a result within a treaty calculation rule and then perform further calculations
based thereon, this result is treated as an interim result.

You can enter this interim result as one of the variables in another rank of the usage type “Minus”.
 Caution
Note that the system can process only released accounts, therefore the Split, Calculate, Release checkbox
must always be set for interim results.
5.1.3.8.3.3 Examples of Treaty Calculation Rules
Case 1
You want to transfer business from the underwriting years from 1999 to 2004 for all property classes of
business in the European Union with the business type “direct” and “indirect” to a quota share retrocession
treaty for a specific company code.
To do this, a quota share retrocession treaty with exactly the coverage scope required is created as an
underwriting year treaty for the years 1999 to 2004. The treaty is created in the company code for the covered
business.
The necessary treaty calculation rule consists of two ranks:
● A plus rank with the text “Treaty Category = Assumed Business”

● A target rank with the target treaty that has been created
The system then posts all entries for the covered scope to the target treaty, irrespective of whether this is
occurrence year, underwriting year, or accounting year business, as long as the underwriting year that postings
are being made for on the assumed business side is between 1999 and 2004.
Case 2
As case 1, but the business of certain cedents is not being retroceded.
These cedents are therefore defined in the plus rank described above as “Excluded”.
Case 3
As case 2, but a specific retrocession that has already been defined on the assumed business side is to be
taken into account. This means that the net quota is posted to the retrocession treaty.
The plus rank contains a setting stating that “specific retrocession” is to be excluded.

Case 4
The net value after deduction of the ceded retrocession quota in case 3 is to be reinsured through a Cat XL
treaty that covers all perils with the exception of terrorism.
A copy of the treaty calculation rule in case 3 is changed as follows:
● No changes are made to the plus rank.

● A minus rank is inserted after the plus rank, containing the quota share retrocession treaty as the selection
criterion.
● The Cat XL treaty is entered in the target rank. You must exclude the peril “Terrorism” for the Cat XL treaty.
If the function to exclude this peril is not available, a limit with the amount zero must be created for
terrorism.
Case 5
Postings for a treaty need to be completely reversed at regular intervals.
To do this, a calculation rule is created with a minus rank, containing the treaty to be reversed as a selection
criterion, and with a target rank containing the same treaty.
Case 6
All matching postings for a treaty need to be copied to another treaty.
As case 5, but a plus rank is used instead of a minus rank.
Case 7
The assumed business described in case 1 now includes facultative business that also needs to be retroceded.
The system copies the posting data of the net result after specific retrocession and deduction of the facultative
cession in the quota share retrocession treaty. The business from certain cedents also needs to be excluded.
The quota share retrocession treaty is created as in case 3:
● In the plus rank, the treaty calculation rule is set to assumed business, contains the exclusion for specific
cedents, and specifies that specific retrocession is to be deducted.
● A minus rank is added and is used for ceded facultative business. The exclusion of facultative retrocession
for the facultative business assumed by the excluded cedents must be handled in a special way. Since
there is no direct method, the facultative cessions affecting these cedents must be processed through
their own facultative master treaties that are defined as “excluded” in the minus rank.
● As in case 3, the quota share retrocession treaty is entered in the target rank, which is now on the third row.

5.1.3.9 Due Date Manager
Use
You use Due Date Manager to define rules. The system uses these rules to perform actions automatically when
a certain event occurs and certain conditions are fulfilled.
You can define these rules either in a treaty or in an event group that you can then assign to any treaties.
You can use Due Date Manager, for example, for treaty-specific reporting or controlling or for monitoring
compliance with authorization totals when the account is released.
Integration
Definition of Event Rules in the Treaty
You define event rules in the treaty on the Due Date Manager tab page at treaty header level.
You can define conditions and actions across the system. This means that you can not only enter certain values
in fields as conditions but you can also refer to an account for this treaty.
Events defined in the treaty cannot be dependent on user groups.
The system does not process events created locally in the treaty with the trigger R2B (transfer to Basic
System).
Definition of Global Event Rules in the Event Group
Two transactions for defining event groups are available on the SAP Easy Access screen under Basic System
Due Date Manager :
● Edit Events (/MSG/REREIGPF)

● Display Events (/MSG/REREIGAN)
You can assign event groups to a treaty. In which case the events contained in the group have the same effect
as the events defined in the treaty. You make this assignment in the treaty on the Header Data tab page under
Accounting Data.
Event groups also provide you with the options of user-group-dependent events and of events during the
transfer to Basic System.
Features
A rule in Due Date Manager contains data in three key areas: Trigger, Condition, and Action Category.
Trigger
Due Date Manager is activated when the event specified in the event rule occurs.
The FS-RI system contains the following triggers as default.

Release an Account
The system checks for this trigger before it releases an account. The trigger is suitable for checking accounts
according to specific criteria.
 Note
You are releasing several accounts when an error message is generated for one of these accounts in the
class or method that was executed. The error message is displayed in the application log for the released
account. The system terminates the release of this account and continues releasing the next account.
Transfer RM Account to Basic System
The system checks for this trigger before it transfers a Risk Manager account to Basic System. The trigger is
suitable for checking accounts according to specific criteria.
 Note
This trigger is available only for rules defined in event groups. The system does not process events defined
in the treaty using this trigger.
 Tip
We recommend you execute the event check for Risk Manager accounts only at this point and that for
performance reasons you do not perform another check when you release the account.
Entry of a Specific Date (Report)
The system reads a base date from a specified date field and uses this, together with the entries in the Interval
Time and Time Shift fields, to calculate the trigger date. This is the date on which the event is triggered by a
report, for example “four weeks before the end of a treaty period”.
To ensure that Due Date Manager recognizes that a certain date has occurred, you must specify in Schedule
Manager that the Check Due Date Rules and Execute Actions [page 551] report is performed daily.
Conditions
You can define conditions that must be fulfilled before Due Date Manager executes the defined action. You can
define different conditions, depending on the event to be triggered.
Possible Conditions for the Trigger “Entry of a Specific Date (Report)”
● Date condition: The current date is the trigger date.

● Data condition: The value of a field in the treaty corresponds to a defined value or value range.
Possible Conditions for the Triggers “Release an Account” and “Transfer to Basic System”
● Data condition: The value of a field in the treaty or in the released account corresponds to a defined value
or value range.
● Amount condition: You can define a threshold value and the total amount posted as a test value. The
condition is valid if the test value exceeds the threshold value.
● The absolute total amount for a calculation base in the account to be released exceeds the value defined
for the user's authorization group.
● The absolute total amount for a calculation base based on the annual total for the current accounting year
exceeds the value defined for the user's authorization group.

● The absolute total amount for a calculation base based on the cumulated value across all accounting years
exceeds the value defined for the user's authorization group.
 Note
You can assign threshold values for authorization groups only to events that have been created in event
groups.
For more information about the configuration of user-dependent event rules, see Use of Authorization
Groups in Due Date Manager [page 339].
Action Name
When the triggering event occurs and all conditions are fulfilled, Due Date Manager executes this action.
The FS-RI system contains the following actions as default:
● Calculation of the due date for the account

● Calculation of the due date for payments (postings)
● Prevention of the release of an account/transfer of an account to Basic System
● Report for sending an automatically generated e-mail [page 340] (/MSG/R_V_DDM_EMAIL)
You can develop other reports or classes and define these as actions. For more information about the
prerequisites for using reports or classes in Due Date Manager, see Prerequisites for Actions in Due Date
Manager [page 338].
Rank
The rank that you enter when you define events controls the sequence in which events and actions are
executed. If you enter two events with the same rank, these events must be distinguished from each other by
the entries in at least one of the following fields:
● Trigger
● Action category
If more than one event qualifies for the execution of similar specified actions, then only the events with the
lowest numerical rank are executed.
Event rules in the treaty always take priority over event rules in groups.
5.1.3.9.1 Prerequisites for Actions in Due Date Manager
Reports and classes are suitable actions in Due Date Manager [page 336]. Both must fulfill certain
prerequisites before you can use them as actions in Due Date Manager.

Prerequisites for Reports
Reports entered as actions are executed in the background and do not influence the program flow. Reports
must meet the following prerequisites:
● The report is an “executable program”.

● When you transfer parameters from the Due Date Manager processing logic, for example account number
or GUID for the rule, you must observe the naming conventions used by Due Date Manager in the report on
the selection screen. You can use the report for sending an automatically generated e-mail [page 340]
(/MSG/R_V_DDM_EMAIL) as an example of this.
Prerequisites for Classes
● The class must be inherited from the base class /MSG/CL_R_V_TRG_ACT. You can use the standard
class /MSG/CL_R_V_TRG_ACT_TOLGRP as a template for the tolerance check.
● You define the class function when you redefine interface method /MSG/
IF_R_V_TRG_ACT~PERFORM_ACTION. Due Date Manager transfers all the supplied parameters to this
interface. This means that you can use this in its own application. You can use the class /MSG/
CL_R_V_TRG_ACT_SYST as an example of this.
5.1.3.9.2 Use of Authorization Groups in Due Date Manager
Use
You can group multiple users with the same authorizations for Due Date Manager in an authorization group.
Prerequisites
The system provides a separate authorization object (/MSG/R_BEG) to assign users to an authorization group.
You can use this authorization object to create roles or profiles for the different authorization groups.
You edit the authorization groups for Due Date Manager in Customizing for FS-RI Reinsurance under Basic
System Basic Settings Authorizations Maintain Authorization Groups .
You assign the roles or profiles to the relevant users in User Maintenance (transaction SU01).
Features
When a user assigned to one of these authorization groups releases an account, the system checks the
amounts and conditions entered in the event. You can have the system check the tolerance values by entering

an amount with a calculation base. If necessary, the system checks the tolerance values for an account several
times for different calculation bases. If the tolerance value is exceeded for one calculation base, the active user
cannot release the account and the system displays a corresponding error message if the class /MSG/
CL_R_V_TRG_ACT_TOLGRP is entered as an action.
Summation Across Multiple Accounts
Amounts should be created only within the account currently being processed (INCRE). The required
calculation of totals when you check events using the entire posting data for a treaty section and an
involvement for the current accounting year (ACYEA) or across all accounting years (ACYEA) is detrimental to
system performance and is not recommended.
Additional Conditions
Additional conditions for events should be kept to a minimum because every additional condition affects
system performance.
Transfer to Basic System
If Risk Manager accounts are summarized when they are transferred to Basic System, the event check includes
the summarized posting data when the amounts are calculated.
Placeholder
When you assign authorization groups in User Maintenance, you cannot assign any general authorizations (the
placeholders "*" and "?") for the authorization object. The system ignores entries that consist only of
placeholders. However, partial authorizations (combinations of placeholders and values) are permitted for user
groups.
If you do not enter an authorization group, the check is performed for all users.
5.1.3.9.3 Sending of an Automatically Generated E-Mail
Use
This report (program name /MSG/R_V_DDM_EMAIL) is an action category in Due Date Manager. You use this to
send an e-mail with standardized content from the SAP system to one or more external receivers.
The report uses the interface that transfers parameters from Due Date Manager [page 336] to the report, and
can be used as an example for customer-specific reports.
Prerequisites
● For this report to function correctly, the administrator must be able to send e-mails in the FS-RI system.
The user who created the rule in which this report is used as an action must enter a valid sender e-mail
address in the user details (transaction SU01). In the SAP Menu under Office -> Workplace- > New
Message, you can see whether the system is able to send e-mails.
● The system can run the report correctly only if it is called up from Due Date Manager. If you run the report
manually this will not produce a result due to an absence of parameter data.

● Before you integrate this report into Due Date Manager you must create a variant for the report, in which
you enter the addresses of the e-mail recipients. You must specify this as the variant for this report in the
rule created in Due Date Manager.
5.1.3.9.4 Example: Setting a Settlement Period If High

Losses Are Incurred
Scenario
Each time an account is released you want the system to check whether the total loss payments for the posted
treaty section and share exceed the limit of EUR 50,000. If this is the case, the system will set the due date for
clearing the open items that are created by the postings in the released account to 14 days after the date on
which the account was entered.
Rule Data
Field Entry
Activity status Active
Trigger Release account
Base date Date of account entry
Interval
Time unit for interval
Time shift 14
Time unit for time shift Days
Amount 50,000
Currency EUR
Exchange rate type Average rate (M)
Amount interpretation Inception-to-date (ITD)
Calculation base Loss payments
Action category System
Action name Payment due date (PAYDD)
You enter an account on January 31, 2003 and release it on the same day. The posted treaty is charged EUR
55,000 in loss payments on this date.

System Actions
1. When the account is released the system checks whether a rule containing this trigger was defined for this
treaty. Result: yes.
2. The system checks whether the conditions in the rule are fulfilled. The only condition is: “total loss
payments higher than EUR 50,000”. Result: yes.
3. The system performs the activity specified in the rule. It adds the specified 14 days to the date on which
the account was entered and as a result sets the due date of the postings to February 14, 2003. This due
date is transferred to the current account.
5.1.3.10 Preparation of Annual Financial Statement After

Accounting Year
Use
You use this function if you want to prepare a financial statement for a treaty after the actual accounting year,
for example if the cedent supplies the closing account for the treaty too late for it to be included in the
statement for the accounting year.
Features
You can enter the time shift in months or years under accounting data on the Header Data tab page in the
treaty, provided the system has not generated any accounts for the treaty. The system observes this time shift
for the following functions.
Use of Parallel Books (Multi-GAAP)
If a derivation rule that is based on the financial year relates to a derivation rule that is based the accounting
year, the difference between the start of the accounting period and the financial period must match the time
shift. If the derivation rules use the same year basis, the time shift has no effect on the rule.
Unearned Premium
If you have entered the time shift in years, the system calculates the unearned premium only if the difference
between the start of the treaty period and the financial period for the account being calculated is less than or
equal to the time shift.
If you have entered the time shift in months, the system calculates the difference in months between the end of
the accounting period and the FI date (it does not take the days into account). The system executes this
function only if the resulting number of months is less than or equal to the time shift entered.
Installment Schedule
In the installment schedule, the system uses the time shift to get any information about the balance sheet date
that may not exist. In doing so, it shifts the due date in the installment schedule back by the period entered in
the time shift.

Statistics Table (Worklist C)
The system calculates in months only (it converts amounts entered in years), but also saves the original unit
entered in the treaty.
5.1.4 Where-Used List
Definition
The where-used list shows all the reinsurance programs, treaty groups [page 343], and losses [page 611]
involving the treaty in question.
Use
You can branch to the corresponding reinsurance programs, groups, or losses by selecting the reinsurance
program number, group number, or loss number.
You can use the New Group Assignment and Delete Group Assignment pushbuttons to change the assignment
of the treaty to treaty groups from the treaty.
5.2 Treaty Groups
You can use the Treaty Group Manager program, which is similar to the Group Manager program in Risk
Manager, to group various treaties (treaty sections).
5.2.1 Initial Screen for Treaty Groups
The selection screen is the initial screen for processing treaty groups and allows you to:
● Display all the treaty groups that meet the selection criteria
● Choose one or more treaty groups to be displayed or edited
● Delete one or more treaty groups
● Create a new treaty group
The selection screen is divided into two sections:
● Selection options
● Overview of treaty groups
When you enter selection options, you can restrict the number of treaty groups that are displayed in the
overview.

You can select treaty groups by treaty category and company code (display mode only).
The “Group Number” has a special role here. When you enter a valid group number and choose ENTER , the
screen for processing the treaty group appears in the mode you selected. However, if you enter a wildcard (*, ?)
in the “Group Number” field and choose ENTER , the system displays all the treaty groups matching this and
the other selection options.
The following attributes are displayed in the treaty group overview: Group Number, Description of Group, Group
Category, Group Category Text, Company Code, Period Start for Group, Changed By, and Created By.
To edit a treaty group, select the group and choose Choose Row or double-click the group.
Possible Actions
● Create
You can create a treaty group in create mode only (if necessary, switch to this mode by choosing Group -
Create). The Create pushbutton is also displayed next to the Group Number field in create mode. When you
create a group, you can enter a new group number or description. If you leave the “Group Number” field
empty, the system automatically assigns the next number in the number range. When you choose the
Create pushbutton, the system branches to the header data for the new group.
● Change
You can change a treaty group in change mode.
● Delete
To delete one or more treaty groups, select these treaty groups and choose the Delete pushbutton. A
confirmation prompt appears asking you if you really want to delete the treaty group. Only logical deletion
takes place at treaty group level. The system does this by setting a deletion indicator. The data is only
removed from the FS-RI database when you archive it. This procedure is referred to as relocation.
5.2.2 Assigning Treaties to Treaty Groups and Removing

Assignments
Prerequisites
The following factors determine whether you can assign a treaty to a treaty group:
● If the start and end date of the treaty period lies within all group periods, you can always assign the treaty.
● If the start date is before all group periods and the end date is before or within the group periods, you can
assign only treaties in which the premium mode and loss mode is set to underwriting year or occurrence
year to a treaty group.
● The group period being assigned must not have a status that allows posting.
● If one of the treaty dates lies after all group periods have expired, you cannot assign a treaty to a treaty
group.
● You can assign sections only to groups belonging to the same category.

Procedure
Assignment in the Treaty
1. Switch to the Where-Used List tab page and choose the New Group Assignment pushbutton.
2. A dialog box appears. Enter the group to which you want to assign the treaty. The system allows you to
select only groups that are suited to the treaty. Alternatively, you can create a new group.
Assignment in the Treaty Group
1. Switch to the treaty group at group period level on the Assignments tab page.
2. Save the assignment. The system calculates the first suitable period and displays the period start date. A
search function is available.
3. When you leave the tab page and switch to the Periods tab page, the system checks whether the assigned
treaties have periods that match the group period, based on the above prerequisites.
4. If you enter a group treaty in the treaty header, the selection of treaties is restricted by treaty direction
(assumed/ceded) and treaty class (life/non-life). This means that you can search only for treaty categories
with the same direction (assumed/ceded). If the treaty you want to assign is also entered as a group treaty
in the group, you cannot enter it as an assigned treaty.
Removing Assignments
To remove the assignment of a treaty to a group, select the treaty in the group on the Assignments tab page
and choose .
When you delete an assignment, the system checks whether the Account Statement checkbox is set for the
group category in Customizing. If it is, you can delete only treaty assignments that do not have released
accounts.
5.2.3 Group Header

You can enter a group treaty on the Group Header tab page.
If you do so, you can assign only treaty sections in the group periods whose treaty has the same direction
(assumed/ceded) and treaty class (life/non-life) as the group treaty.
If you do not enter a group treaty, you can assign treaty sections with different directions and treaty classes.
A group treaty is a statistical treaty for which you must set the Statistics and General Ledger checkboxes in the
treaty category.
You must set the premium mode and loss mode for all the sections in a group treaty to Accounting Year across
all periods.
All the periods in the group treaty must be covered by the group period. In other words, the group treaty must
not have a period dated before the group period.
You cannot calculate a group treaty or assign it to a different treaty.
This field can be defined as a required entry field in Customizing for every group category.
You can also create an Extension Service for the group header with further details on the Extension Service tab
page. You can define this field in the Customizing activity for group categories. The group category is then
automatically entered in this field when you create a new group.

5.2.4 Group Periods
The group period divides the period for the group into individual parts for assigning the treaty sections. The
periods can run to any date in the future. In other words, they cannot contain gaps.
Every group period has a status. This status defines whether the specific group period can be processed
(posting allowed), or whether it has been canceled.
Any changes you make to the status of the group or of the assigned treaty section do not affect the others. So,
if you change the group to a status that allows posting, the assigned treaties are not automatically set to a
status that allows posting.
When you set the status of a period to a status that “allows posting”, the system performs certain checks on
the period:
● Group treaty
○ The system checks whether the assigned treaties all have the same direction (assumed/ceded) and
treaty class as the group treaty.
○ The system checks the main class of business of the assigned treaty sections and group treaty. This is
performed only for non-life treaties and if the main class of business is set in the Customizing activity
for group categories.
● General
○ The system checks the periods of the assigned treaty sections (in accordance with the premium mode
and loss mode).
○ The system checks that an assigned treaty section does not occur more than once in the same group
category and period.
The treaty category and group treaty are displayed on the Group Periods tab page for information
purposes.
Possible Actions
● Create
You can define a period only by entering a start date. The end date is the beginning of the next period and is
entered automatically by the system. You cannot change this date. If you have defined an account group or
forecast and estimation group, the Start Date and Accounting Frequency fields in Customizing must be
filled. The start date specifies when a group period begins. The accounting frequency defines the time
intervals in the period.
● Delete
You can delete a group period if the treaty assignments do not contain any treaties that have released
accounts. The system checks this only if you set the Print checkbox in the Customizing activity for group
categories.
● Change
You can change the entries in the Status, Change Reason, and Extension Service fields.

5.3 Accounting Process
Use
This process uses the treaty basic data and the premiums and losses incurred to calculate the payments due
between business partners and post the corresponding amounts in the current account system.
The current account system contains open items that need to be paid.
Prerequisites
Before you release an account, the treaty periods for which the account is created must have a status that
allows posting.
Process
Manual Accounts
1. You create an account with at least one posting by choosing Account -> Create (transaction /MSG/R_A1).
2. You split [page 358] the account to distribute the amounts for treaties with different business partners.
3. You calculate [page 359] the account to incorporate the results of treaty conditions.
4. You release [page 365] the account.
5. The system creates the relevant open items in the current account system.
Accounts Created By Background Job
There are a number of background jobs you can run to perform the above process flow, or parts thereof.
For more information, see Account Processing [page 530].
5.3.1 Account
Definition
The business object Account is a collection of postings for a treaty. These are either postings that occur over a
certain time period or postings that occur as the result of a certain event.
 Note
The FS-RI object “Account” should not be confused with the year-end or quarterly account that you send to
your reinsurer or retrocessionaire. This statement can contain data from several account objects. For more
information about this account, see Billing/Account Statement [page 467].

Use
You use the account as a “shell” for postings. You cannot make a posting without an account and for this reason
SAP Reinsurance Management for SAP S/4HANA (FS-RI) always uses accounts when a posting is to be made.
You can create accounts manually, or have them generated by the system.
In addition to the standard actions Create, Edit, and Delete, you can perform the following actions for an
account:
● Split: The system splits the posting data for an account according to treaty involvement.
● Calculate: You can calculate result-independent conditions and create condition postings.
● Release: You can transfer posting data to the current account system.
● Reverse: You can offset released posting data in the current account system.
● Print: Posting items can be grouped and sorted in the current account statement.
● Check Conditions: You can check the result-independent conditions posted in an account and create
adjustment postings.
For more information about accounting functions, see the relevant subsections in this documentation.
Account Status
Accounts can have different statuses, such as “Split”, “Copied”, and “Released”. The system resets the status
when it performs an accounting function.
If you perform a function manually, the account is assigned the status determined by the system.
If you perform a function using a background job, you can define an alternative status before starting the
background job for the generated or processed accounts.
The system processes the accounts in the way needed to achieve the target status.
Structure
The account comprises header data (Account tab page) and posting data (Postings tab page). The header data
indicates, for example, the treaty, section, and business type to which the account applies. The posting data
details the posting amounts, accounting and underwriting year, areas, and so on, for each posting in the
account.
Integration
Treaty
An account is always assigned to a treaty or treaty section.
In accounts created manually for ceded treaties, you can also enter the assumed treaty number and the
assumed section number. The system then identifies and saves the assumed cedent.

Only assumed treaties or connecting treaties that contain the account cedent as the reinsurer can be entered
as suitable assumed treaties.
The selected assumed section must cover all the structural characteristics that were specified in the postings
and the account header. This does not apply to accounting units. The system also checks the coverage area,
peril, and exclusions of any assigned loss.
Loss
You can also create an account from a loss.
Current Account System
Accounts are used to forward postings to the current account system. For more information, see Posting [page
349].
Background Jobs
You can generate accounts using background jobs; for example, if you want the system to calculate and post
the results of treaty conditions at year-end. For more information, see the documentation for the background
jobs.
5.3.1.1 Post
Use
The system uses a posting to transfer amounts from a specific company code in the FS-RI system to the
integrated current account system (FS-CD). If these amounts represent payments to be made or received, the
system triggers open statuses in the current account system.
However, a posting can also be purely statistical and, as such, does not trigger liquid items.
Integration
In the system, postings are always grouped together, and displayed, in accounts. A posting takes effect only
when you release the corresponding account manually or using a background job.
Prerequisites
The following prerequisites must be met before a posting can be made:
● You have correctly integrated the current account system to which the amount is to be posted.
● You are authorized to post amounts to the integrated current account system.

Features
In the current account system, postings trigger open items. Postings also contain a range of important
information, including the following.
Entry Code
Each posting has an entry code. An entry code is always used for a specific posting type or usage. The entry
code comprises a number of attributes that apply to a posting.
You define entry codes in external Customizing for Basic System under Accounting Entry Code .
In Customizing you also define the entry code assigned to a posting created for a specific posting type.
Data
In addition to the posting date (found in the account), in the FS-RI system each posting also contains the
assigned underwriting and occurrence date.
Entry Code Attributes
Depending on the entry code, a posting can be liquid or non-liquid, and may be purely statistical, or relevant for
financial accounting.
Entry Codes
The amount to be paid or received is displayed in the original currency (the currency in which the amount
payable is determined) and is automatically converted to the account currency (the currency used for the
actual payment). The system also displays the underwriting and occurrence years of the posting, and the class
of business for which the posting is to be made.
Activities
The following steps are performed for a posting:
1. An event occurs for which a posting is to be made. For example, you create a loss, or the background job
run annually for the account recognizes that the annual premium for a treaty is due.
2. The system generates the posting in an account.
3. You release the corresponding account (manually or using a background job).
4. The posting is sent to the current account system and becomes effective.
5.3.1.1.1 Handling of Accounting Units in a Posting
If an accounting unit is assigned to a treaty containing postings, this accounting unit is also a characteristic of
the posting. If this is a local accounting unit, the system determines the assigned global accounting unit from
the local accounting unit.

Special Features in Life Treaties
If the account is based on a life treaty, the system always determines the class or line of business from the
accounting unit.
5.3.1.1.2 Calculation of the Due Date for a Posting
Use
The due date is the date by which a posting must be paid.
A due date is assigned to every cash posting and to every fund posting in the system.
In the current account system, you can use the due date to control certain functions, such as dunning, or to
trigger payment.
Features
The system calculates and assigns the due date for every posting, whether entered manually or automatically.
You can use the following methods to calculate the due date of a posting.
Automatic Determination of the Rules for Calculating the Due Date
The system has several methods of automatically calculating the due date of a posting. The method that is
used depends on the settings in Customizing. You define the rules for these methods in external Customizing
for Basic System under Accounting Configure Method of Calculating Due Date .
For more information about these methods, see:
● Methods for Automatic Calculation of Due Dates in Basic System [page 352]
● Methods for Automatic Calculation of Due Dates in Risk Manager [page 169]
Treaty-Specific Rules for Calculating the Due Date
If you want to apply different rules from those defined in Customizing to a certain treaty, you can use Due Date
Manager [page 336] to define your own rules for calculating the due date in the treaty.
Rules entered in Due Date Manager have a higher priority to rules entered in Customizing.
Manual Creation or Changing of the Due Date
If you want to define a different due date for a posting from that calculated by the rules in Customizing or by
Due Date Manager, you can manually overwrite this date in the posting provided the account has a status that
can be changed.
If the system cannot calculate a due date, it does not fill the field provided and you must enter the date
manually to be able to release the account.

5.3.1.1.2.1 Methods for Automatic Calculation of Due Dates in
Basic System
The system uses the methods described here to automatically calculate the due dates for postings.
Calculation Based on Time Limits Entered in the Treaty
The system calculates the due date for the posting according to the evaluation of account creation periods
[page 353].
Transfer of the Due Date From the Installment Schedule
In the case of generated postings, the system copies the due date from the installment schedule in the treaty.
In the case of manual postings, the system does not fill the “Due Date” field.
Setting to “Not Due”
The system sets the due date to December 31, 9999.
Entering the Current Date
The system uses the current date when it creates the posting.
Using the Due Date of the Original Account
The system uses the due date of the original account. This may be relevant for accounting functions such as
“Split” or “Transfer to Basic System”.
 Note
In the case of treaty calculation rules, in some cases the system may not be able to find an original account
if you do not set the Individual Accounts checkbox in Customizing for Basic System under Default Values
Edit Defaults for Accounting (Calculation Fields) .

No Default Values
The system does not fill the “Due Date” field; you must enter this date manually.
User-Defined Methods
If you require additional methods to those delivered in the system, you can develop these as individual
enhancements and make them available in internal Customizing under Maintain Accounting Settings Edit
Method of Calculating Due Date . For more information, contact your SAP consultant.
5.3.1.1.2.1.1 Calculation of Due Dates According to Time

Limits
1. The system identifies the accounting periods of the treaty. The duration of the individual accounting
periods is indicated by the accounting frequency. The position of the accounting periods is determined by
the first accounting key date, which specifies the last day of the first accounting period. Subsequent
accounting key dates occur at the intervals specified in the accounting frequency.
2. The system calculates the due date for account processing. It does this by determining the accounting key
date of the accounting period that contains the date on which the account was received and adding the
account creation period to this date.
3. The system calculates the due date for the posting. It does this by adding the account review period and
the settlement period after account receipt or after account confirmation to the due date for account
processing. (You can specify only one of the two time limits in the treaty).
Calculation of Due Dates According to Time Limits Using Example Values
Treaty period Treaty: Treaty Period January 1, 2007 – December Manual entry
31, 2007
Accounting frequency Treaty: Header Data 1/2Y (half-yearly) Manual entry
First accounting key date Treaty: Header Data July 10, 2007 Manual entry
Account creation period Treaty: Header Data 15 days Manual entry
Settlement period after ac Treaty: Partners Involved 20 days Manual entry
count receipt

Settlement period after ac Treaty: Partners Involved (none) Manual entry
count confirmation
Account review period Treaty: Partners Involved 10 days Manual entry
Date received Account: Account June 5, 2007 Manual entry
Accounting period Internal period (for details of 1/1/2007 – July 10, 2007 ● First accounting key
calculating this period, see date = July 10; account
step 1) ing periods after July 10
occur at half-yearly in
tervals
● Date received (June 5,
2007) lies in the period
January 1, 2007 – July
10, 2007
Accounting key date Internal date (for details of July 10, 2007 = end date of accounting pe
calculating this date, see riod (see above)
step 1)
Due date for account proc Account: Account (for details July 25, 2007 = July 10, 2007 (end date of
essing of how to calculate this date, accounting period) + 15 days
see step 2) (account creation period)
Due date for posting Account: Posting August 24, 2007 = July 25, 2007 (due date for
account processing) + 20
days (settlement period after
account receipt) + 10 days
(account review period)
The figure below illustrates the example with a half-yearly accounting

frequency.
[insert figure]
5.3.1.1.3 Reserve Posting
Use
Reserve postings are generated to create provisions (for losses, for example) or carryforwards (for premiums,
for example).

For more information about reserves, see Reserves [page 290].
Prerequisites
You have created a specific entry code for the reserves in external Customizing for Basic System under
Accounting Entry Code Edit Entry Code Definitions .
Features
Entry of Reserve Postings
You can enter reserves wherever you can enter other postings. For example:
● On the Postings tab page in an individual account

● In a bordereau
● In a loss
You can also enter reserves on the following designated screens in the account, which offer additional
functions:
● On the Reserves tab page: Here you define reserves according to classes and lines of business. The system
displays the totals for reserve postings with the same structure, which gives you a clearer overview of the
current reserve balance for this structure. The system includes all reserve postings from current accounts
and those released at an earlier date.
● On the Total Reserves tab page: Here you define reserves independently of classes and lines of business,
and area. The system displays the totals for all reserves, which gives you a clearer overview of the current
reserve balance for the treaty section for which postings have been made.
When you save the account or loss, the system updates the data on the other tab pages with the changes
made.
Clearing or Posting or Delta
You can either change the reserve amounts by posting a change amount (delta) or by clearing the entire
amount and reposting the target amount. You can do this in external Customizing for Basic System under
Defaults Values Edit Defaults for Accounting (Calculation Fields) .
Effectiveness of Reserve Postings
Reserve postings can be relevant for financial accounting or purely statistical. This is defined by the entry code
used for the posting. You define this in external Customizing for Basic System under Accounting Entry
Code Edit Entry Code Definitions .
● If the entry code is relevant for financial accounting, the financial year must match that of the account.
● If the entry code is statistical, the accounting year must match that of the account.
● If entry codes are statistical and relevant for financial accounting, the financial and accounting year must
match those of the account.
This enables the system to determine the total for the postings so that it can calculate the reserve.

Reversal of Accounts
When you reverse an account, you can deactivate the reversal of reserve postings according to company code
and the actual/estimate indicator. You make these settings in external Customizing for Basic System under
Default Values Edit Defaults for the Reverse Function .
Reserve Carryforwards
You use the background job Carry Reserves Forward to Target Year [page 546] to carryforward reserves when
you switch from one period to another.
5.3.1.1.4 Fund Posting
Use
You can use this function to control the document creation for fund postings.
For more information about funds, see Funds [page 260].
Prerequisites
In Customizing under FS-RI Reinsurance Basic System Accounting Entry Code Edit Entry Code
Definitions , you have created the corresponding entry code for this specific fund.
Activities
In Customizing under FS-RI Reinsurance Basic System Interfaces FS-CD Interface Maintain Technical
Settings , you specify how you want to create the documents for fund postings:
● If you do not select the No Posting to Fund Insurance Object checkbox, the system generates two business
partner items when you release fund postings (subledger transfer posting):
○ A business partner item for the treaty insurance object
○ A business partner item for the fund insurance object
● If you select the No Posting to Fund Insurance Object checkbox, current account documents for fund
postings are not posted separately to a fund insurance object as open items when you release fund
postings. In this case, the system creates the following items in the FS-CD system:
○ A business partner item for the treaty insurance object
○ A general ledger item
 Note
This new method of document creation works in the same way as the document creation for cash
postings and prevents open items from being generated for the fund insurance object. The fund
insurance object itself is not generated.

Open items for the fund insurance object are usually never cleared, which can negatively affect the
system's performance when you display the account balance.
Dependencies
Before you select the checkbox, make sure that all current items for the fund insurance object have been
cleared.
If you reverse existing fund postings after you have selected the checkbox, the system applies the current
Customizing setting.
 Note
This system behavior also applies to the reversal of estimates.
5.3.1.2 Editing Accounts
Prerequisites
● You are authorized to edit accounts.

● You have not released the account (exception: you can still copy and reverse the account).
● You have not split the account (exception: you can still copy the account).
● The account is not reversed. (exception: you can still copy the account).
Procedure
You can use the following functions to edit accounts.
Create In the navigation tree, choose
Account Create .
Save When you save an account, the system

Choose .
fills the certain dependent fields using
the current treaty data and performs
various checks.
Change In the navigation tree, choose
Account Change .
Display In the navigation tree, choose
Account Display .

Copy Regardless of the status of the source

In the source account, choose ; in
account, the system assigns the status
the menu bar, choose Account
"Pending" to the target account. You
Copy (or choose F7 ). can then make any changes to the tar
get account.
Delete In the navigation tree, choose ● You can delete an account only if it
has not been released.
Account Display .
● In the case of reversed FGU ac
Search for the account but do not open counts, you can delete only the
it; instead choose Edit Delete . original account together with the
reversal account.
● In the case of split accounts, you
must always delete the original ac
count.
5.3.1.3 Splitting Accounts
Use
You use the Split function to create individual accounts for the involvements for a treaty from an overall account
for a treaty.
Features
This function creates individual accounts for the individual involvements from an overall account (100%
account) for all involvements for the treaty, provided you have not entered a share in the source account.
Whether the system creates an account for an involvement depends on the applicability of the participations
for the involvement (for example, the written line does not apply). The system includes only participations for
RI-related involvements with a signed line > 0, a status that allows posting, and a period of validity that covers
the start of the accounting period for the account.
It also includes result-independent conditions of the category “Stop”, “Filter”, or “Transfer Posting”, with the
portfolio rule accounting time “With Every Account”.
Because the system considers reinsurers only, when it splits accounts for assumed treaties it creates only one
account for the own share. Nevertheless, you can also create an account for a co-reinsurer.

Activities
You can call this function as follows:
● In an account, choose the Split or Split, Calculate pushbuttons.

● In a background job that creates an account, select a target status for the account created that contains
the split.
When it splits an account, the system performs the following:
● It converts the postings for all involvements relevant to the account according to their signed line
percentages and creates corresponding pending accounts and postings.
● If an assumed treaty in a different company code participates in a share (only possible in Basic System),
the system creates an account for the company in the company code and also an account for the
participating treaty. The share of the company is entered in the latter, which means that this account is not
split.
● It calculates the partial accounts in which a share is stored.
● It creates a 100 % account for information purposes.
5.3.1.4 Calculating Accounts
Use
You use the Calculate function when the treaty for which the account is created contains conditions. The
system calculates the postings incurred by the conditions based on the existing premium and loss posting data
for the account, and adds these to the account.
Prerequisites
● The account to be calculated has the status Pending.

● You have split the account to be calculated and have saved a share in the account to be calculated.
Features
Sequence
The system calculates conditions and the retention and release of funds in the sequence described in Funds
Retained and Release of Funds [page 261]. Results from lower ranks are entered in the calculation bases for the
higher ranks if these contain the lower ranks as reference ranks.

Activities
You start the calculation process in the account by choosing the or Split, Calculate pushbutton or in the
menu bar by choosing Account Calculate ( F6 ). The system performs the following activities:
1. First, it combines the amounts of the postings, whose entry codes are included in the calculation base for
the condition, to form an assessment basis. The plus/minus sign of each partial amount depends on the
Customizing settings for the respective entry code and the calculation base.
2. In the second step, the system multiplies the assessment basis by defined percentage rates or calculated
PRT rates and assigns the target entry code (“Target”). The amounts are not posted directly at this stage.
Instead, they are first compared with postings that have a matching structure (“actual”).
3. In the third step, either the calculated difference or a negative “actual” (reversal) and positive “target”
posting is made. This depends on the Customizing settings.
5.3.1.5 Calculate Taxes
Use
You can use this function to calculate taxes for an account’s entire postings and transfer these to the current
account system (FS-CD).
Prerequisites
● The account is proportional, final, and has not yet been released or transferred to Basic System.
● You have installed FS-RI 7.0 SP11.
● You have made the following changes in Customizing:
○ In Customizing under FS-RI Reinsurance Basic System Accounting Tax Calculation Define
Criteria for Tax Liability , you specify which tax is to be used for which characteristics (such as class
of business, area). You do not define a specific tax type, instead you define a tax determination code
that contains several tax types. In the business partner (on the Reinsurance tab page), you define a
unique area for each of the three partners (cedent, reinsurer, payment partner).
 Tip
We recommend that you do not use any entry codes in the calculation bases for the tax calculation
that are defined as LUD entry codes in Customizing under FS-RI Reinsurance Basic System
Accounting Entry Code Entry Codes for Limits and Deductibles .
○ In Customizing under FS-RI Reinsurance Basic System Accounting Tax Calculation Assign
Condition Type to Tax Entry Code , you specify the target entry code for each tax.
○ In Customizing under FS-RI Reinsurance Basic System Accounting Entry Code Edit Entry
Code Definitions , make sure that the Transf. FI (Transfer Entry Code to FI) and Man. Post. (Manual
Posting Allowed) checkboxes are not selected for the tax entry codes.

Features
You can perform the tax calculation in Basic System and in Risk Manager from the account overview and in
account processing.
 Note
Note that the tax calculation is not integrated in any background job. This means that you can perform the
tax calculation only online.
Activities
You perform a tax calculation as follows:
1. Alternative A: You perform the tax calculation from the account overview.
○ From the SAP Easy Access menu, search on the account screen for the accounts with the postings for
which you want to calculate taxes.
○ In the search results, select the accounts for which you want to perform the tax calculation.
Alternative B: You perform the tax calculation in account processing.
○ From the SAP Easy Access menu, search on the account screen for the accounts with the postings for
which you want to calculate taxes or create a new account.
 Note
For more information about creating an account, see Editing Accounts [page 357].
○ In the search results, select the account for which you want to perform the tax calculation.
○ Jump to the account for which you want to perform the tax calculation.
2. Choose the Tax Calculation pushbutton.
3. The system displays:
○ An error message: If the prerequisites have not been met; for example, the system could not find any
unique entries in the Customizing activities mentioned above. In this case, the system terminates the
process.
○ A success message: If the taxes could be calculated. In this case, the system saves the calculated taxes
and creates these as new postings in the account being processed. You can change only the original
amount for these postings. For example, you may want to manually adjust rounding differences.
 Note
If you perform the tax calculation again, the system discards all the existing tax postings for an
account and performs an entirely new calculation.
Alternative C: You perform the tax calculation in NWBC Loss Management application.
○ Search in the NWBC Loss Management application for the activity with the accounts for which you
want to perform the tax calculation.
○ Jump to the activity in which you want to calculate the taxes.
○ On the Preview of Details or Preview of Cedent View page, choose the Tax Calculation pushbutton in
the toolbar.

○ The system calculates the taxes for all the existing accounts for the selected activity and displays
these on the detailed page on the Preview of Details page.
4. Choose the Release pushbutton (Finalize) to close the account and send the data to the FS-CD current
account system.
 Note
It is not possible to perform the tax calculation for postings that are generated after release.
Transfer to FS-CD
After you have released an account with tax postings, the system copies the original posting, including the tax
information, to the FS-CD current account system. This means that the FS-CD document for the original
posting contains these generated tax postings as single tax items under Taxes.
Deletion Behavior
If you delete the source postings for taxes that have already been calculated, the system also deletes the
corresponding tax postings.
If you delete only specific tax postings for an account, the remaining tax postings that have already been
calculated, including the source posting, are not deleted.
If you change one of the following criteria relevant for the tax calculation, the system deletes all the taxes
already calculated from the account:
In the account header:
● Account level
● Account cedent
● Accounting period
● FI posting date
● Involvement
At posting level (source posting for tax):
● Entry code
● Original amount
● Payment partner
Perform the tax calculation again to ensure that you have the most up-to-date and accurate tax data.
Handling in Accounting Functions
Reverse Account
When you reverse accounts for which you have already performed a tax calculation, the system also reverses
the corresponding tax postings. Tax postings with opposite plus/minus signs are then entered in the reversal
accounts. The corresponding tax information is entered in the reversal documents in the FS-CD system.
Copy Account
When you copy accounts for which you have already performed a tax calculation, the system does not copy the
tax information to the target account. If you want to add the tax information to the target account, you have to
perform the tax calculation for the affected target accounts again.

Delete Account
When you delete accounts for which you have already performed a tax calculation, the system also deletes the
tax information for the account.
Transfer to Retrocession
Basic System
When you transfer accounts for which you have performed a tax calculation to retrocession, the system copies
the tax postings as manual postings to the target accounts. These are no longer displayed as taxes.
This system behavior applies to the following functions in Basic System:
● Use of treaty calculation rules (in a background job)

● Transfer to specific retrocession
● Release of accounts for a connecting treaty or participating treaty
However, you can use result-independent conditions to stop or transfer tax postings in the case of a
transfer to specific retrocession or with the use of treaty calculation rules.
Adjustment After Changing Signed Line
If the system is using accounts for which the tax calculation has already been performed as the actual
balance for a signed line (SL) adjustment, it does not evaluate the tax information within the adjustment
posting.
You have to perform the tax calculation again for the adjustment postings created by the SL adjustment to
ensure that you have the most up-to-date and accurate tax data.
 Note
To ensure that you can perform the tax calculation after the SL adjustment, do not use the value
“Release” as the scope of processing for the SL adjustment.
Handling in Risk Manager
Transfer to Basic System Without Direct Release of an Account from Risk Manager
The system transfers the tax postings, including the tax information, to the Basic System account. After you
release these accounts, the system enters the taxes in the FS-CD documents.
Transfer to Basic System with Direct Release of an Account from Risk Manager
When you release accounts directly in Risk Manager, the system transfers the tax postings to the Basic System
account as manual postings. The taxes are then displayed in the FS-CD documents for the Risk Manager
account.
Tax Calculation in NWBC Loss Processing
In the NWBC Loss Processing [page 655] application you can calculate taxes for preview accounts on the
Preview of Cedent View page and view these on the Preview of Details page. The process is the same as that
described above for all accounts for the current activity.

5.3.1.6 Check Conditions of an Account
Use
You use this function to check an account's postings against the result-independent conditions and deposit
rules agreed in the treaty and to create any necessary adjustment postings.
Prerequisites
● The account being checked has already been released, will be released by a background job, or has the
status "Pending".
● You can use the Transfer Adjustment Postings function only if the account has not yet been released.
Features
The system calculates the result-independent conditions and deposit rules in the same way as the Calculate
[page 537] function. It compares the results with the account's postings and creates adjustment postings that
are displayed in a dialog box. The agreed percentage and related calculation base, the target value, the actual
value and the difference between these two values (as an absolute value and in percent) are entered in this
dialog box.
You can transfer these adjustment postings to the account.
Depending on the Customizing settings, either the calculated difference is posted or a negative “Actual”
(reversal) and positive “Target” value is posted.
5.3.1.7 Check Limits
Use
You can use this function to check an account's postings against the limits entered in the treaty.
Prerequisites
● The account being checked is pending, has already been released, or will be released by a background job.

Features
The Check Limit function is always executed for one single account. The system checks the postings for the
selected account only. It also checks the postings for all accounts that have already been released provided
they fall within the same limit as the postings for the account being checked.
If the currency has to be converted, the system converts the amounts into the LUD currency or into the leading
section currency.
The system displays the agreed amounts from the treaty as well as the actual utilization for each treaty as an
amount and as a percentage. You can determine from the utilized percentage whether the limits entered in the
treaty have been exceeded.
The information is displayed in the LUD currency or in the leading section currency.
Limit Check for Proportional Treaties
The system checks the limits using the calculation bases entered in the LUD data for the category “Limit” (see
also Detailed Description of Limits, Underlyings, Deductibles (LUD) [page 273]). The sequence of the ranks for
the individual limits is not important.
Single loss LUDs contain only accounts with loss numbers.
The system does not check the limit control (area, peril, and so on) because there may not be any assignments
between a loss and treaty or any loss reference.
Limit Check for Non-Proportional Treaties
The system uses the amounts covered to create the totals for non-proportional treaties. It includes only those
postings whose entry codes are entered in the LUD entry codes (Customizing).
Multiline and multiyear limits are included.
Interlocking, indexation, and alternative LUDs are not supported.
5.3.1.8 Release of an Account
Use
When it releases an account, the system sends the postings for the account to the integrated SAP current
account system.
Prerequisites
● The account has the status “Pending” or “Released” (all variants).

● You have assigned a partner involved and cedent to the account.
● The treaty period has a status that allows posting.

Features
When it releases an account, the system performs the following actions:
● It sets the status of the account to “Released”. This means that no further changes can be made to the
account.
● It runs all the checks relevant for the account and its postings. If a critical error occurs, the account is not
released.
● It uses the work table for the ledger group [page 555] for the relevant postings to find the corresponding
ledger group (if you have activated the use of a ledger group [page 481]). It then transfers this ledger group
and the posting to the FS-CD system.
● It creates participating accounts in a different company code (if certain treaty scenarios involve postings in
all company codes). For more information, see Accounts for Connecting Treaties [page 200].
● It creates opening reserves from posted closing reserves, provided you have made this setting in external
Customizing for Basic System under Default Values Edit Defaults for Accounting .
● It fills the statistics tables.
● It sets retrocession checkboxes for sections containing retrocession data.
● It runs the limit check (see Check Limits [page 364]), provided you have configured this check in external
Customizing for Basic System under Default Values Edit Defaults for Accounting . You can choose the
following settings for this check:
○ Warning if limit exceeded
The system checks the limit when you release an account. The system displays a warning message if
the limit is exceeded. If you are releasing the account from the screen, you can confirm the warning
message or cancel the release. If you are releasing the account in a background job, the system
releases the account and logs the warning message.
○ Error if limit exceeded
The system checks the limit when you release an account. The system displays an error message if the
limit is exceeded. The account cannot be released.
○ No check
The system does not check the limit when you release an account.
The limit check is not available in any parallel background jobs that release accounts, with the exception of
background job /MSG/R_ABR_BATCH_PP ("Split, Calculate, and Release Accounts: Parallel Processing per
Treaty").
5.3.1.8.1 Derivation Rules
Use
You can use derivation rules to specify that postings entered in a set of accounts (book) are also entered in
other, parallel, books.

Prerequisites
You have made the necessary settings in the following activities in external Customizing for Basic System:
● Accounting Accounting Principles Edit Accounting Principles

● Accounting Accounting Principles Assign Accounting Principles to Entry Codes
● Accounting Accounting Principles Assign Accounting Principles to Company Codes
● Accounting Accounting Principles Edit Derivation Rules
Features
Derivation rules automate the postings to different books. When you release the relevant accounts, the system
uses the rules defined in Customizing to create derived accounts. In doing so, for each entry code in the
account the system checks whether a valid derivation rule is assigned to this entry code in the current
company code. If this is the case, the system creates a derived posting with the target entry code specified in
the derivation rule for this posting in the derived account. The target entry code indicates which book, and
therefore which accounting principle, is affected.
5.3.1.8.2 Exclusions for Derivation Rules
Use
You can enter exclusions for derivation rules. These exclusions allow you to support specific accounting rules.
You can use the combination of positive derivation rules and specific exclusions to reduce the number of
posting rules to be specified.
Furthermore, you can use the enhancement achieved by this to control the scope of these rules in more detail.
You can restrict the few derivations created by a wildcard using differentiated exclusions.
You can also differentiate between actual and estimate indicator and class of business. In addition, you can
make a distinction between Final and Estimate and Class of Business.
Prerequisites
Before you can work with exclusions for derivation rules you have to make the required settings in Customizing
for Basic System under Accounting Accounting Principles Edit Exclusions for Derivation Rules .
 Note
The following is a generic entry that is valid for all company codes and FAS classifications.

Company Code Valid From Entry Code Target Entry Code FAS Classification
4022 4122
4022 4322
4042 4342
4042 4142
5022 5122
It can be combined with exclusions so that the derivation rules for all other company codes (with the
exception of those that have been excluded) no longer apply.
Company Code Valid From Entry Code Target Entry Code FAS Classification
AB01 4022 4322
DS02 4022 4122
AB01 4042 4342
DS02 4042 4342
By way of comparison: If we assume that the company codes AB01, AB02, AB03, DS01, and DS02 exist,
we would need 21 entries for these (5 company codes x 5 entry codes - 4 exclusions). If we use exclusions,
only 9 entries are required.
5.3.1.9 Reversing Accounts
Use
You use the “Reverse” function to reset an account that has already been released.
Prerequisites
You have released, but not yet reversed, the account.

Activities
1. In the account to be reversed, choose Account Reverse .

2. The system generates a new account that is identical to the original, but whose postings have opposite
plus/minus signs. This account is released immediately and cannot be changed.
 Note
In external Customizing for Basic System under Defaults Values Edit Defaults for the Reverse
Function , you can deactivate the reversal of reserve postings in an account.
5.3.2 Non-Proportional Account
In an FGU account (from ground up), postings are recorded for a cedent across treaties so that these can then
be distributed to treaty sections assigned to a loss.
When it distributes postings, the system considers the liability or coverage data entered for the treaty sections.
You do not therefore need to create individual accounts for each of the treaties.
The process flows in the non-proportional account itself always refer to the LUD entries for the treaty sections
assigned to the loss.
In principle, you could assign or edit proportional treaty shares, or combinations of proportional and non-
proportional treaty sections, within the loss for the non-proportional account. To do so, you must define a
processing sequence.
Surplus treaties are not processed by the non-proportional account, but can be assigned in the loss.
In addition to the different liabilities and excess points defined on the “LUD” tab page, you can also define a
reinstatement schedule in the treaty sections, which is also included in the non-proportional account. In the
same way, you can enter data for indexation parameters on the “NP Liability” tab page in the non-proportional
treaty section. These are referred to in the non-proportional account and accounts are created accordingly.
You can calculate non-proportional liabilities in two ways:
● You can consider the postings proportionally according to their amount (pro rata).
● You can weight the postings according to the time of creation (“first come, first served”).
5.3.2.1 Multiline and Multiyear Liabilities
Use
Multiline or multiyear liabilities specify that the total sum of the specific coverage data are limited to specific
amounts.

In addition to the specific limits for a treaty period or for different coverage characteristics, other general limits
are agreed in certain reinsurance areas (for example class of business or area). These limits restrict the total
liability across the treaty periods or coverage characteristics.
 Note
Multiline and multiyear liabilities are only supported for non-proportional treaties.
Integration
The system integrates the multiline and multiyear liabilities in all application areas and background jobs for the
non-proportional calculation.
Prerequisites
You have defined the corresponding aggregation and LUD categories in the system.
You can edit and define aggregation categories and their assignments in Customizing for FS-RI Reinsurance
under Basic System Treaty NP Data Edit LUD Category .
Features
Identification of Treaties
If multiline or multiyear liabilities apply to a treaty, you must indicate that this treaty is relevant for multiline or
multiyear liabilities on the Header Data tab page under Additional Data.
On the LUD tab page at header level in a treaty, you can then enter liabilities across sections or periods:
● A liability that is defined across sections applies to one treaty period. This period is defined by the
corresponding start date.
● A liability that is defined across periods applies to one section. This section is defined by the section
number.
The ranks specified for multi-LUDs must not be smaller than or equal to the ranks that are already being used
in lower levels.
You can use only LUD categories whose aggregation category is not specific to the treaty section (specified in
fields VTGNR, VTGJJ, and BESTNR).
The applicable LUD criteria must be covered by all involved sections.
Multiline and Multiyear at Share Level
On the treaty screen, the system checks that multiline and multiyear LUDs can only be calculated at share level
if the coinsurance percentages are the same in all periods and sections (depending on the multiline and
multiyear settings).

 Note
For multilines: The coinsurance percentages in a period must be the same for all sections.
For multiyears: The coinsurance percentages must be the same for each section in all periods.
Restrictions on Processing of Multiline and Multiyear Liabilities
● The system does not support the processing of reference ranks in conjunction with multiline and multiyear
liabilities.
● The calculation of multiline and multiyear liabilities at share level is only supported if the same
involvements in each of the sections covered by the multiline and multiyear LUD have the same shares.
● Interlocking is completely excluded in conjunction with multiline and multiyear liabilities.
● Multiline and multiyear liabilities are not supported in facultative business.
● The liability relationship “All Applicable Liabilities” is not supported in conjunction with multiline and
multiyear liabilities.
● The following non-proportional liability data must be the same in all the treaty sections affected by
multiline and multiyear LUDs:
○ Covered amounts
○ Protected share
○ Loss adjustment expenses
○ Non-proportional calculation mode
● Pro rata structural characteristics are not supported in treaties with multiline and multiyear liabilities.
● Indexation is not supported for multiline and multiyear LUDs.
● Multiline and multiyear LUDs are not supported in the alternative LUDs.
 Note
Example
Constellations for Multiline
The following constellation is permitted.
Period 2010
Section 1 Section 2
SL 80% SL 80%
SL 20% SL 20%
The following constellation is not permitted - (*) denotes the row with a problem.
Period 2010
Section 1 Section 2
SL 80% SL 60% (*)
SL 20% SL 20%

Constellations for Multiyear
The following constellation is permitted.
Period 2010 Period 2011
Section 1 Section 1
SL 20% SL 20%
Section 2 Section 2
SL 50% SL 50%
The following constellation is not permitted - (*) denotes the row with a problem.
Period 2010 Period 2011
Section 1 Section 1
SL 20% SL 20%
Section 2 Section 2
SL 50% SL 30% (*)
5.3.2.2 Franchise
Use
In addition to deductibles and liabilities, you can agree franchises for treaties.
A deductible and the corresponding liability are not applied as long as the payments or reserves for a loss do
not exceed this franchise.
Integration
The franchise LUDs are integrated in all application areas and background jobs for the non-proportional
calculation.

Prerequisites
You have defined the corresponding LUD category in the system. You can edit and define this category in
Customizing for FS-RI Reinsurance under Basic System Treaty NP Data Edit LUD Category .
You have also defined statistical entry codes for the postings below a franchise for all entry codes that can be
used in the non-proportional accounts.
You must also enter these entry codes in Customizing for Basic System under Accounting Entry Code
Entry Codes for Limits and Deductibles .
Features
Franchises are a type of margin and are positioned in front of LUDs.
The system processes these LUDs that follow franchises only when the total entered in the franchise LUD has
been exceeded.
If the franchise is not exceeded, the system posts to the entry code defined for “Below Franchise” in
Customizing under Entry Codes for Limits and Deductibles.
 Note
Franchise LUDs can be entered in Basic System treaties. They are not permitted in Risk Manager
participations.
The following constraints apply:
● Franchises are permitted in the first limit; they are not permitted in LUDs with the 2nd Calculation Step
checkbox.
● Franchise LUDs do not allow interlocking.
● Franchise LUDs do not allow indexation.
● Franchise LUDs are not permitted if the liability relationship is “All Applicable Liabilities”.
● The system does not support the processing of a reference rank in conjunction with a franchise.
● The system supports “Pro Rata (Old)” and “Pro Rata Structural Characteristic” but adjustments are never
required because in the case of a limit everything is always either above or below the margin. The
prerequisite for this is that a franchise with LUDs with the 2nd Calculation Step checkbox is not permitted.
When it determines whether margins have been exceeded, the system includes closed loss amounts under
“Executed”. However, these amounts are not used for posting purposes.
 Note
LUD entries in treaty section:
Franchise: USD 120,000
Deductible: USD 100,000
Liability: USD 500,000

FGU Posting in Loss Postings to Treaty Share According to Loss Account
Loss payment 1: USD 115,000 Below franchise: USD 115,000
Loss payment 2: USD 50,000 Below franchise: USD -115,000
Below deductible: USD 100,000
Loss payment: USD 65,000
5.3.2.3 Meaning of the Screens Used in the Treaty
On the Header Data tab page, you must set the Section Unique checkbox.
You must also make an entry in the Amount Reference field. In this field you specify whether the data on the
LUD tab page is already in-force or whether it is entered at cedent level.
 Example
An amount of EUR 1 million entered as a liability on the LUD tab page with the amount reference “Original”
and an own company’s share of 50% in an assumed treaty corresponds to an insured value of EUR 2 million
(from the point of view of the cedent).
You must enter the following in the liability data for a non-proportional treaty:
● Loss adjustment expenses

Here you specify how the loss adjustment expenses are handled. The following settings are possible and all
the available options can be found in the field help in the FS-RI treaty:
○ Excluded
Expenses are never covered.
○ Within limit
Loss adjustment expenses are handled like normal loss payments and calculated against the limit.
○ Pro rata
Loss adjustment expenses are copied with the same percentage as the loss payments without being
calculated with these payments.
○ Unlimited
Loss adjustment expenses are always covered regardless of the total.
● Amounts covered
The system uses the covered amounts to identify which postings are payments, annuity reserves, normal
reserves, loss adjustment expenses, and reserves for loss adjustment expenses. You must enter the
amounts covered in Customizing under Treaty -> Amounts Covered (Calculation Bases). The system
assigns a calculation base number to each of the five different types of amounts covered. You define this
calculation base in external Customizing for Basic System under Accounting Edit Calculation Bases
and Rules The definition contains a collection of entry codes necessary for the non-proportional account
of this type for the amount covered. Furthermore, a non-proportional account can work only if you specify
whether the entry codes contained in the calculation bases for the amounts covered are to be used as
entry codes for from-ground-up, franchise, deductible, limit, annual aggregate deductible, or annual

aggregate limit. You specify this in Customizing for Basic System under Accounting Entry Codes for
Limits and Deductibles .
● Liability relationship
Here you specify the calculation logic that controls the interaction of LUD entries for which you have not
set the 2nd Calculation Step checkbox. You can enter the following:
○ Liability with the highest rank
If more than one liability applies for an FGU posting, only the one with the highest rank on the LUD tap
page is processed by the non-proportional account.
○ All applicable liabilities
All applicable liabilities are used.
You can also enter more data about the indexing of loss postings and about the “protected share” in the
non-liability data.
● Protected share
This indicates the percentage by which all the postings needed for calculating non-proportional liability
must be multiplied. This also adjusts the liability data. If the amount reference Original is entered on the
Header Data tab page, the system does not multiply the protected share.
● lndex data
You can map the cost development related to a period in the FS-RI system. To do this, the system uses the
loss payments accrued across different posting periods to index excess point and liability. The system then
uses these indexed values to create an account for the non-proportional liability.
● Index type
This is the reference value for cost evaluation (wages and salary index, construction costs index, and so
on). You define indexes in Customizing under Treaty Edit Index Definitions .
● Indexation clause
Here you specify the indexation clause used (full index clause, severe inflation clause). This is used in long
tail business to determine the rise or fall in value, for example as a result of inflation. The deductible and
liability are adjusted according to one of the above methods to spread the inflationary risk fairly between
the primary insurer and reinsurer.
● Base year
This is the base year for calculating any agreed indexation clause.
● Margin
The indexation clause is applied only if the change in the index for the year concerned in relation to the
base year exceeds this value.
● Period
Here you specify the timeframe within which the index table entries must be viewed. The system uses the
accounting frequency, period start date, and year of validity entered in Edit Index Definitions together with
the period entered here to determine the correct index value for an FGU posting created in the loss
transaction. It also indexes the calculation parameters for the non-proportional account.
● LUD tab page in the treaty section
Here you enter the calculation values relevant for the non-proportional account. The system uses a ranking
sequence to include all possible excess points and liabilities (from single losses to loss events to annual
liabilities or annual deductibles).
● Rank
The system processes entries in ascending order.
● LUD category
Here you specify the category of maximum liability, deductible, or franchise. You can create different values
in Customizing. For example, it makes sense to enter categories that refer to a single loss, large loss, loss
event, or a treaty year (for example, for AAD/AAL). You make the necessary settings in Customizing as

follows: You define the aggregation category for the calculation value for the non-proportional account in
Customizing under Treaty Edit and Assign Aggregation Categories . For example, you can enter the
aggregation category "Loss" with the reference field SCHADNR and treaty period and section in table /MSG/
RBU. The non-proportional account then automatically recognizes losses to be calculated in combination
(these are the losses that share the same limitation category). In Customizing under Treaty Edit LUD
Category , you use the defined aggregation category as a base to make the actual entry on the LUD tab
page. In this Customizing activity, you specify whether the LUD is a limit or a deductible or a franchise,
which aggregation category is to be used, and whether a second calculation step is to be applied to the
LUD. If you set the 2nd Calculation Step checkbox, the system calculates the LUD category in the second
calculation step (for example, an annual aggregate limit).
● Maximum amount
Here you enter the amount for which the LUD entry (LUD Category) is to be processed in the non-
proportional account.
● Currency
This is the ISO currency code. If you enter a currency, the system only considers accounts for this
currency. If you do not enter a currency, you must enter the amount in the leading currency of the section.
You can therefore enter a currency to filter data. The system does not convert postings entered in other
currencies into the specified currency.
● Exchange rate type
This is the exchange rate to be used to convert currencies.
● Area
This defines the hierarchy of a geographical assignment, where the higher-level areas include the lower-
level areas. For example, “Europe” includes Western Europe, and Germany is included in Western Europe.
You enter and define the area hierarchies on a separate screen. If you enter an area, this entry is only valid
for losses in the indicated area. As with the currency, the area can also be used to filter data.
● Peril
Along with other attributes, you can assign a peril to a loss. The peril indicates the cause of the loss. If you
enter a peril on the LUD tab page, this peril is valid only for losses assigned to the specified peril. As with
the currency and area, you can use the peril to filter data.
● Loss class
This is another way of categorizing losses in order to limit deductible and liability.
5.3.2.4 Meaning of the Screens Used in a Loss
At “cedent” level, you assign to the loss the cedents whose treaties will cover a loss.
When you save the header data for the loss, the system automatically enters the owner company as the first
cedent. You can enter companies from the current company code.
● Cedent
This is the company that reported and reinsured the loss.
● Status
You can use the status to lock the editing of a cedent. The status determines whether a loss is open (can be
edited) or closed (locked).
On the Treaty Assignments tab page, you can enter the treaties for the loss in which the company previously
assigned to the cedent is entered as the cedent.

● Treaty
This is the treaty assigned to the cedent.
● Assignment date
The system automatically enters the loss date in this field; however, you can enter any date.
● Period start
This is the start date of the treaty period containing the assignment date.
● Section
This is a section in the assigned treaty.
● Account transfer
If you set the Account Transfer checkbox, the system processes the assigned treaty section in the usual
way. If you do not set this checkbox, the system does not include the section when it distributes FGU
accounts. However, if you set the Account Transfer checkbox, you can set the Account Transfer for
Information Purposes checkbox to specify that the distributed account is saved with the corresponding
loss number, but that an offsetting posting of the same amount and without a loss number is created
before this distributed account is released. This necessary when, for example, a proportional treaty is
combined with a non-proportional treaty in the non-proportional account and a separate account is
created for the proportional treaty; the influence of the quota share still needs to be included in the non-
proportional account. If you do not set the Account Transfer for Information Purposes checkbox, the loss
would either be recorded twice (if the Account Transfer checkbox is set for the quota share), or the
influence of the quota share would not be considered (if the Account Transfer checkbox is not set for the
quota share). The default setting of this checkbox is determined by the setting for the Loss Posting for
Information checkbox in the assigned treaty section.
● Rank
This defines the order in which the treaties are processed.
● Reference rank
This specifies the predecessor rank to which the treaty refers. This means that the system can include
different sliding scales of liability data from different treaties. The amounts underlying the calculation of
the current rank are the amounts not yet covered by the reference rank. If the reference rank is 0, the full
amount is always available for distribution.
As a result, the ranking order of treaties with the same reference rank plays no role.
● Status
You can use the status to lock the editing of a treaty. The status determines whether a treaty is “open” (can
be edited) or completed (“locked”). If the status locks the section, the system does not include it in the
FGU distribution.
● External references
You can enter an external document (for example, an insurance policy) or its number in this field.
You enter the reason for the last change to a loss (technical reason for the change).
● Additional data structure
You can enter the number for an additional data structure. This structure is expanded and displayed on the
Additional Data tab page. The FGU Postings (Account) view is needed for entering the postings that are
assigned directly to the loss. Distribution to the assigned treaties takes place according to the fields
specified in addition to the data relevant for posting (such as class of business, business type, and area).
● Account
A number is provided here that uniquely identifies the account. This number is automatically assigned by
the system when you save your entries.
● Status

This is the status of the account. You can create a non-proportional account “from the ground up” only for
accounts with the status FGU Pending. When you create a non-proportional account for the selected FGU
account (by choosing the Calculate Loss pushbutton), the system changes the status to FGU Distributed
and you cannot create another non-proportional account.
● Entry code
This specifies how the system is to handle the amount posted (Amount in Original Currency); for example,
whether the entry code is for a loss, premium, reserves, funds, or portfolio. You enter an exact definition for
the entry codes in external Customizing under Accounting -> Entry Code -> Edit Entry Code Definition.
● Original amount
This is the amount posted in the original currency.
● Original currency
This is the currency in which you want to enter the posting. If you create the non-proportional account after
entering the FGU posting, the currency entered here is compared with the currency entered on the LUD tab
page in the assigned treaty sections; if these do not match, the FGU posting is filtered out.
This is the class of business of the posting. A posting is covered by the sections assigned to the loss only if
the classes of business entered for the section include the class of business specified here.
● Line of business
This field plays a similar role to the Class of Business field, depending on the country specified. As with the
class of business, the posting is covered only if the line of business entered in this field is included in the
lines of business entered for the assigned treaty section.
● Underwriting year
This is the underwriting year of the posting (entered in the format YYYY).
This is the underwriting date of the posting (entered in the format DD.MM).
● Occurrence year
This is the year in which the loss occurred; this field is automatically filled by the system.
● Occurrence date
This is the date of the loss; this field is automatically filled by the system.
● Financial year
This is the year in which the posting is included in the financial statements.
● Accounting year
This is the year in which the cedent’s account was created. This cannot be after the financial year.
● Period
This is a section of the accounting year (quarter, month, half-year). As well as transferring the data for this
accounting period to the distributed account, the system uses the data entered in this field together with
the accounting year to find the correct index entry (if indexation is defined under Index Data).
● Area
This defines the hierarchy of a geographical assignment, where the higher-level areas include the lower-
level “areas”. For example, Europe includes Western Europe, and Germany is included in Western Europe. A
posting is covered only by assigned sections that cover the area of the posting. As with the original
currency, the posting is also filtered using the LUD entry (LUD Category field), if applicable.
● Business type
This is the type of reinsurance business (direct, indirect) or corresponding structural characteristics. A
posting is covered only by assigned sections that cover the business type of the posting.

5.3.2.5 Interlocking
Use
Generally, loss events affect more than one policyholder and, consequently, more than one policy. These
policies may have been concluded for different underwriting years, areas, or classes of business. For
reinsurance, this means that a single loss event can affect multiple periods and sections of a treaty and that the
treaty must therefore cover a higher part of the loss than specified in the individual period or section.
Interlocking clauses specify that in this case, and depending on the interlocking type, the deductible and
liability are reduced in the affected sections or periods as a percentage of the total expenditure. For each LUD
the system calculates the size of the percentage share of the entire interlocking loss in this section or period;
only this percentage is applied to the corresponding LUD.
Interlocking clauses are supported for non-proportional treaties only.
Integration
Interlocking ratios are calculated in the following functions:
● Online loss account

● Background job for treaty calculation rules
● Background job for retrocession accounts
● FGU background job
● Background job for recalculating FGU
● FGU distribution using pro rata method (excluding structural characteristic)
Interlocking ratios are recalculated if changes are made.
Prerequisites
● In the treaty with interlocking, you have set the Section Unique checkbox on the Header Data tab page
under Control Data.
● If the interlocking type for a treaty is Underwriting Year, you have set the loss accounting mode to
Underwriting Year in all sections.
Features
Identification of Treaties
If a treaty is relevant for interlocking, you must indicate on the Header Data tab page under Additional Data
whether this is section interlocking or underwriting year interlocking.

On the LUD tab page you must also set the Relevant for Interlocking checkbox for all the LUDs in the treaty that
are relevant for interlocking.
Section Interlocking
In the case of section interlocking, the interlocking ratio is calculated across all sections that are affected by a
common loss event. The FGU posting amounts are distributed proportionately to the sections by the
interlocking rule based on the selected LUDs in the different sections of a treaty within a period.
Underwriting Year Interlocking
In the case of underwriting year interlocking, the interlocking ratio is calculated across all the periods that are
affected by a common loss event. The FGU posting amounts are distributed proportionately to the periods by
the interlocking rule based on the selected LUDs in the different periods of a treaty within a section header.
Currency Conversion
To calculate the interlocking ratio, the system translates the original amounts for the accounts into the local
currency (of the company code for the treaty).
If the interlocking ratio is calculated in a background job, the FI posting date and the exchange rate type
entered in the section are used to do this.
If the interlocking ratio is calculated online, the current date and the exchange rate type entered in the section
are used to do this.
Account Adjustment
If a new interlocking ratio is created by later postings and the subsequent changes to FGU amounts, when the
system calculates the new postings it recalculates all the amounts linked by interlocking and posts the
differences.
Change of Interlocking Type
You can change the interlocking type for a treaty to "Section" or "Underwriting Year" retrospectively. The
system does not support the complete deactivation of interlocking (the interlocking type is changed to
"None"). If you want to deactivate interlocking for a treaty, you can deactivate the Relevant for Interlocking
checkbox for the corresponding LUD entries instead.
 Note
Example 1
A loss that affects two policies, one for the class of business "Fire" and the other for the class of business
"Business Interruption", is reinsured by two different sections.
The fire section is provided with a coverage of 6 xs 3 million and the business interruption section with a
coverage of 9 xs 6 million. Losses of 6 million are incurred for the fire policy and losses of 12 million are
incurred for the business interruption policy.
As a result, the ratio for the fire section is 33.33% and for the business interruption section is 66.66%.
The coverage to be applied to the business interruption policy is (9 xs 6) x 66.66% = 6 xs 4.
The coverage to be applied to the fire policy is (6 xs3) x 33.33% = 2 xs 1.
The losses incurred for the business interruption policy are reinsured to the amount of 6 million. The losses
incurred for the fire policy are reinsured to the amount of 2 million.

 Note
Example 2
A loss that affects two policies, one from the underwriting year 2006 and the other from the underwriting
year 2007, is covered by an underwriting year treaty. For the underwriting year 2006, the treaty provides a
coverage of 5 xs 5 million; for the underwriting year 2007, this is 8 xs 8 million.
Losses of 12 million are incurred for the 2006 policy and losses of 8 million are incurred for the 2007 policy.
As a result, the ration for the underwriting year 2006 is 60% and for the underwriting year 2007 is 40%.
The coverage to be applied to the 2006 policy is (5 xs 5) x 60% = 3 xs 3.
The coverage to be applied to the 2007 policy is (8 xs 8) x 40% = 3.2 xs 3.2.
The losses incurred for the 2006 policy are reinsured to the amount of 3 million.
The losses incurred for the 2007 policy are reinsured to the amount of 3.2 million.
Activities
1. Determine Existing Posting Data

In the first step, the system finds the existing posting data. This includes the net figures already billed at
treaty level in the loss.
2. Determine Affected LUD
In the second step, the system determines which LUDs in the treaty are affected by the loss posting.
Interlocking is applied only to LUDs with the same LUD category, such as "Single Loss" or "Loss Event".
3. Calculate Interlocking Ratio
To calculate the interlocking ratio, the system determines the size of the share of posting data for the
individual affected LUDs in relation to the entire posting data.
4. Calculate LUDs to Be Applied
To calculate the amount to be posted to an LUD, the system multiplies the number of LUDs entered in the
treaty by the share determined in step 3. The same applies for the deductible and liability or for AAD and
AAL.
5.3.2.6 Examples
The following examples demonstrate, step-by-step, the entries you need to make in the various functions to
successfully calculate a non-proportional account.
They also explain how you can navigate between the individual functions.
The examples cover the following topics:
● Example 1:Basic non-proportional account [page 382]

● Example 2:First come, first served versus pro rata [page 383]
● Example 3:Calculation of reinstatement premiums [page 383]
● Example 4:Indexation [page 387]

● Example 5:Effect of the liability relationship on LUD entries [page 391]
5.3.2.6.1 Example 1: Basic Non-Proportional Account
Entries in the Treaty
As already mentioned in the treaty overview, you must enter data in the Loss Adjustment Expenses and
Amounts Covered fields on the NP Liability tab page; these are required entries for calculation of the non-
For the purposes of this example, enter "LAEIL (Loss Adjustment Expenses Within Limit)" in the Loss
Adjustment Expenses field; this means that the system always handles loss adjustment expenses like a loss
payment or a loss reserve.
In the Amounts Covered field, enter "10 (Standard with Separated LAEs)"; this means that the system uses
separate entry codes for the loss adjustment expenses and their reserves. In the case of reserves, based on the
current Customizing settings the system evaluates only one reserve and does not evaluate a separate annuity
reserve. In this example, the liability relationship specifies the application of the liability with the highest rank.
As an additional adjustment to the treaty, you must enter the data for the liability amounts. You do this on the
LUD tab page. Let us assume you have an excess point and a maximum liability that both refer to single losses.
The correct LUD categories for this are "DEDUC Deductible (Single Loss)" and "LIAB Liability (Single Loss)".
Enter the following amounts: EUR 100,000 for deductible, and EUR 500,000 for liability; this produces an XL
structure of 500,000 XS 100,000.
Entries in the Loss
Create the loss as normal and then perform the following actions.
Switch from the Loss Processing tab page to the Cedents tab page. When you save the loss for the first time the
system enters the owner company as the cedent. Enter the cedent from the treaty previously adjusted as an
additional cedent.
To assign the treaties to the loss, select the row containing the cedent for which a matching treaty exists and
choose .
The treaty assignment screen appears. If you click the first field Treaty Number and ask the system to display a
selection of the treaties (F4), it displays only those treaties that contain the previously selected cedent as the
company.
When you select the required treaty, the system automatically fills the Section, Start Date, and Assignment
Date fields. However, entries are required for the Rank, Reference Rank, and Status fields. You must enter a
consecutive rank for each assigned treaty (for this example “1”). The reference rank specifies the rank to which
the treaty refers (in this case “0” because there is no preceding rank). The status indicates whether the treaty
still accepts data for processing (in this example, "O for Open").
Switch to the Account tab page to enter the FGU postings (inward postings).

You enter the posting data directly for the loss, specifying the entry code, amount, currency, business type,
class of business, and area. Note: The area, class of business, business type, and line of business entered must
be the same as those for the adjusted treaty; also, in the case of underwriting date, occurrence date
(automatically determined from the assignment date in the loss header), or start of accounting period, a
current period with a status that allows posting must exist in the assigned treaty section.
For the purposes of this example, create a loss posting (entry code 3100) with the amount EUR 800,000. When
you save the FGU posting, the system automatically assigns an account number. Next, select this row and
trigger the accounting function by choosing the Calculate Loss pushbutton. The system sets the status of the
FGU account to FGU Distributed and calculates the non-proportional account.
To view the results of this calculation, switch to the Treaty tab page, select the row containing the specified
treaty, and choose . The Treaty Figures screen appears. If you have performed all steps correctly, the result
should be EUR 100,000 for under deductible, EUR 500,000 for loss payment, and EUR 200,000 as maximum
liability.
5.3.2.6.2 Example 2 (Pro Rata Capita Distribution)
Pro rata capita distribution can be carried out at fixed times, for example before quarterly financial statements,
based on the results of the NP loss account.
This example explains the difference between first come, first served (FCFS) and pro rata capita using example
1. First enter and create an account for a second FGU posting for another class of business.
The second FGU posting is for EUR 800,000 in entry code 3100 (loss payment). After you have calculated the
loss payment, you can see that this posting is completely assigned to the area above the limit.
Pro rata capita distribution ensures that the amounts from both classes of business are redistributed according
to their share of the total amount to the areas under deductible, within liability, and in excess of liability.
Two methods of pro rata capita distribution are available, which work at different levels of granularity:
● Method 1: Pro rata capita distribution related to a single loss

You can use the /MSG/R_A_BATCH_FGU_PROR_PP background job (FGU Distribution "Pro Rata Capita"
(Parallel)) to carry out pro rata capita distribution, whose resulting postings are posted to single losses.
● Method 2: Pro rata capita distribution across losses
You can use the /MSG/R_A_BATCH_NP_PR_SC_PP background job (Pro Rata Capita Distribution by Struc.
Charac. (Parallel)) to carry out pro rata capita distribution, whose resulting postings are posted without
reference to single losses.
This method generates fewer postings than method 1, especially for annual loss or loss event coverages,
since it is easier to aggregate.
5.3.2.6.3 Example 3: Calculation of Reinstatement

Premiums
This example demonstrates how the reinstatement premium is automatically calculated by the non-

The system uses the following formula to calculate the reinstatement premium from the loss load for the XL
treaty and the subject premium:
Reinstatement Premium = (Subject Premium) x (Loading Factor) x (XL Loss Load / Layer) x Date Factor
The date factor in the above formula is determined by the calculation method for the reinstatement premium. If
this calculation method is “Pro Rata Capita”, the date factor is always “1”. This means that when you calculate
the reinstatement premium it is not important when the loss relevant for the XL treaty occurred. However, if the
calculation method is “Pro Rata Temporis” the date factor is calculated as follows:
Date Factor = (Period End – Loss Date) / (Period Duration)
This considers the fact that the probability of a loss reoccurring in the current treaty period decreases if the
remaining duration of the treaty period is shorter. To calculate a reinstatement premium in the case of example
1, you need to enter additional data in the treaty section. To determine the subject premium for the above
formula, the following expressions are evaluated one after another and the first that differs from zero is used:
1. Final premium
2. Final subject premium x minimum premium installment
3. Final subject premium x fixed premium installment
4. Advance premium
For the purposes of this example, the subject premium is calculated from the advance premium. First you must
enter the advance premium. For this example, enter EUR 100,000 as the amount on the Installments tab page
in the treaty section.
Select the entry and branch to the next screen by choosing the pushbutton. Here you specify how the
payment of the advance premium is distributed to the individual payments. You can either do this manually or
distribute the treaty already defined by choosing “Generate Installment Schedule”. The result is the division of
the total amount into one or more parts. In this example, the advance premium must be paid in one installment
at the beginning of the treaty period.
Once you have entered the advance premium, you must define the reinstatement schedule. Before you can
maintain the “Reinstatements” tab page, you must set the “Reinstatement” checkbox on the “NP Premium”
tab page.
You can then enter the reinstatement schedule. For this example, enter the following data.
Number From Number To Reinstatement Cover % Reinstatement
1 1 100 Pro rata capita
2 2 50 Pro rata capita
You have entered a loading factor of 100% for the first reinstatement and 50% for the second (and last)
reinstatement. If you enter the loading factor in the “Reinstatement Cover %” field only, the system
automatically enters “Pro Rata Capita” as the reinstatement method If you want to calculate reinstatement
using the Pro Rata Temporis method, you must enter the loading amount in both the Reinstatement Cover %
and the Reinstatement Time % fields.
The system uses the data on the LUD tab page for the non-proportional calculation. You can, in principle, enter
several different liabilities on the LUD tab page in a treaty section; however, on the NP Premium tab page you
need only enter the reference rank from the LUD table for the liability for which the reinstatement premium is
to be calculated. In this case, choose “Liability (Single Loss)”.

To trigger the non-proportional account, including calculation of the reinstatement premium, create a loss
(according to example 1) with an FGU posting of EUR 550,000 and the entry code 3100 (loss).
Distribute this first FGU posting for loss 1 to the assigned treaty section by choosing the Calculate Loss
pushbutton. The system displays the following result for the distributed account in the display screen for the
account.
Entry Code Original Amount Amount Posted
3100 Loss payment 450,000.00 887,818.50
7004 Loss payment below attachment 100,000.00 197,293.00

point
1708 Reinstatement premium 90,000.00 177,563.70
Using the formula above, the system calculates the reinstatement premium as follows:
Reinstatement Premium = 100,000 x 100% x (450,000 / 500,000) x 1 = 90.00
If you create a second FGU posting of EUR 200,000 for loss 1, only the remaining XL load of EUR 50,000 is
effective and the distributed account generated with the non-proportional account contains a reinstatement
premium of EUR 10,000.
This is calculated as follows, and can again be seen in the display screen for the account: 100,000 x 100%
x (50,000 / 500,000) x 1 = 10,000.
3100 Loss payment 50,000.00 98,646.50
7003 Loss payment above liability limit 150,000.00 295,939.50
To check that the loading factor for the second reinstatement was processed correctly, create a second loss
with a posting of EUR 2 million FGU.
When you check the distributed account that is generated, the reinstatement premium should be EUR 50,000
(100,000 x 50% x (500,000 / 500,000) x 1 = 50,000).
3100 Loss payment 500,000.00 986,465.00

point
7003 Loss payment above liability limit 1,400,000.00 2,762,102.00

The creation of a reinstatement schedule always implies that an annual aggregate limit (AAL) has been defined:
(Number of Reinstatements + 1) x (Layer to Which the Reinstatements Refer) = (Implicit) AAL
There are three distinct cases in which you explicitly enter an AAL in addition to the reinstatement agreement:
1. Implicit AAL from reinstatement > explicit AAL from LUD:

Reinstatement only up to the explicit AAL; amounts that exceed the explicit AAL are above AAL.
2. Implicit AAL from reinstatement < explicit AAL from LUD:
Reinstatement premium is calculated up to the implicit AAL; reinstated amounts that go beyond this range
are exempt from premiums.
3. Implicit AAL from reinstatement = explicit AAL from LUD:
There is no difference to the calculation without explicit AAL.
Let us look at the case if you do not enter an explicit AAL. Create two further losses (loss 3 and 4) with
respective FGU postings of EUR 1.5 million and EUR 150,000. The distributed account for loss 3 does not
contain any postings above AAL because the layer is available three times.
3100 Loss payment 500,000.00 986,465.00

point
7003 Loss payment above liability limit 900,000.00 1,775,637.00
However, the distributed account for loss 4 does include a corresponding posting above AAL (in this case, the
accounting mode is set to “FCFS” in Customizing).

point
7003 Loss payment above AAL 50,000.00 98,646.50
The account date and the utilized amount are entered in the reinstatement schedule in the treaty section. The
following table shows the results after the non-proportional account has been created for all FGU postings for
all four losses.
Number From Number To Reinstatement Reinstatement Amount Uti Amount Uti Total Amount
Cover % lized for Cash lized for Non- Utilized
Payments Cash Pay
ments
1 1 100 Pro rata capita 500,000 0 500,000
2 2 50 Pro rata capita 500,000 0 500,000

You can see from this table that reinstatement postings (reinstatement reserves) have also been created for
the loss reserves that occurred. These are displayed separately from the reinstatement premiums in the
reinstatement schedule. The total utilized amount is the sum of the amounts utilized for cash and non-cash
payments.
5.3.2.6.4 Example 4: Indexation
This example demonstrates indexation in a non-proportional account in the FS-RI system.
During indexation, loss burdens in a non-proportional reinsurance treaty caused by index-related burdens (for
example, inflation of medical costs within the obligatory liability insurance for physicians) are distributed fairly
between primary insurer and reinsurer.
All loss payments are index adjusted to a uniform reference date, and the calculation parameters for the XL
coverage (liability, excess point) are adjusted using the quotient from a nominal and index-adjusted loss
amount. The amounts adjusted in this way are then used to create accounts for the actual loss. More
specifically:
In this example, using the original treaty in example 1, enter the following data in the relevant fields on the “NP
Liability” tab page in the treaty section:
● Index type: 100 test index (defined in Customizing)

● Base year: 1986
● Period: year
● Margin: 5%
You must also enter the indexation clause for all LUDs on the “LUD” tab page, whose amount is adjusted
according to the value:
● Indexation clause: standard inflation clause
Index Type
In this field, you enter the index type specified previously in the treaty on the “LUD” tab page (Customizing for
FS-RI Reinsurance under Basic System Treaty NP Data Edit Index Definitions ).
The Customizing screen is divided into two sections. First you enter the header data for the index series: index
number "100", index type "test index", base year "1985", area "DE". You enter the actual indexation on a
different subscreen. Enter the following index percentages for this example.
Year Index Percentage
1985 100
1986 103.8
1987 107.7444
1988 111.8386872
1989 116.088557314

Year Index Percentage
1990 120.499922492
1991 125.078919546
1992 129.831918489
1993 134.765531392
1994 139.886621584
1995 145.202313205
1996 150.720001106
1997 156.449361148
1998 162.392360872
1999 168.563270585
2000 174.968674867
You use the accounting frequency and start date entered in this subscreen to define the period of validity of the
index entry.
Indexation Clause
Here you enter the calculation method for index adjustment. You can select STD (standard inflation clause) or
SIC (severe inflation clause).
Base Year
The base year entered here is used later to calculate indexation. It must be at least as late as the base year
entered in the index definition.
Margin
Depending on the indexation clause, here you enter the required margin for the selected calculation method.
Period
There are different possible accounting periods, depending on the accounting frequency you enter in the index
definition. For example, if you specify that accounting takes place every three months, accounts can also be
created for the treaty section every three months, and also every six months or every year. For this reason, you
must enter the specific accounting period in the index data.
Below is an overview of the calculation procedure.
The coverage is as follows.
LUD Type Amount Indexation Clause
Deductible 100,000 STD

LUD Type Amount Indexation Clause
Layer 500,000 STD
The corresponding FGU postings produce the following result.
FGU Amount Accounting Year FGU Amount (Indexed to 1986 – STD

– 5%)
200,000 1987 200,000 because (107.7444 / 103.8) <

1.05
150,000 1992 119,924
70,000 1996 48,209
Total:
420,000 368,133
All the FGU postings here refer to a loss. Indexation is an important issue for losses that are paid out a long time
after they occur. For example, the indexed loss amount for the FGU posting of 70,000 would be 70,000 x
(103.8 / 150.720001106) = 48,209. The suitable index entry is determined based on the posting period of the
FGU account and read from Customizing, and then the loss is recalculated.
In a second step, layer and excess point are indexed as follows: Result:
Adjusted deductible = 100,000 x (420,000 / 368,133) = 114,089
Adjusted layer = 500,000 x (420,000 / 368,133) = 570,446
This results in the following with regard to the calculated coverage.
FGU Amount Below Deductible Covered Above Limit
420,000 114,089 305,911 0
These abstract amounts are depicted in the system by entering three FGU postings.
Status Entry Code Original Amount Accounting Year
FGU pending 3100 Loss payment EUR 200,000 1987
The system then calculates the FGU accounts one after another and creates the following distributed accounts.
Distributed Account for Accounting Year 1987

Entry Code Underwriting Year and Occurrence Original Amount
Year
3100 Loss payment 3100 Loss payment EUR 100,000
7004 Loss payment below attachment 3100 Loss payment EUR 100,000
point

Year
3100 Loss payment 3100 Loss payment EUR 140,599.12
7004 Loss payment below attachment 3100 Loss payment EUR 9,400.88
point

Year
3100 Loss payment 3100 Loss payment EUR 65,311.64
7004 Loss payment below attachment 3100 Loss payment 4,688.36

point
The following table shows how the results obtained fit into these calculations. This is the result if all received
distributed postings are aggregated.
Accounting Year Below Deductible Covered Above Limit
1987 100,000.00 100,000.00 0
1992 9,400.88 140,599.12 0
1996 4,688.36 65,311.64 0
Total: 114,089.24 305,910.76 0
This means, after aggregation, the (rounded) numbers above match the summary of accounts in the FS-RI
system.

5.3.2.6.5 Example 5: Liability Relationship
You use the Liability Relationship field to enter different calculation methods for the different limits entered on
the LUD tab page. You can enter different limits on the LUD tab page. This example concerns the following
different liabilities.
Rank LUD Category Maximum Amount
1 DEDUC – Deductible (Single Loss) 1,000,000
2 LIAB – Liability (Single Loss) 1,000,000
3 LRDED – Deductible for Loss Reference 1,000,000
4 LRLIA – Liability for Loss Reference 1,250,000
5 OCDED – Deductible (Loss Event) 1,000,000
6 OCLIA – Liability (Loss Event) 1,500,000
The individual liabilities themselves are defined in Customizing with several layers. First define the LUD
category in external Customizing for Basic System under Treaty NP Data Edit LUD Category .
LUD Category LUD Type Aggregation Category 2nd Calculation Step
1 – LIAB – Liability (Single Limit 1 No

Loss)
2 – DEDUC – Deductible Deductible 1 No

(Single Loss)
3 – OCLIA – Liability (Loss Limit 2 No

Event)
4 – OCDED – Deductible Deductible 2 No

(Loss Event)
5 – AAL – AAL Limit 4 Yes
6 – AAD – AAD Deductible 4 Yes
7 – TTLIM – Treaty Period Limit 4 No

Limit
8 – TTDED – Treaty Period Deductible 4 No

Deductible
9 – LRDED – Deductible for Deductible 5 No

Loss Reference

LUD Category LUD Type Aggregation Category 2nd Calculation Step
10 – LRLIA – Liability for Loss Deductible 5 No

Reference
11 – Annual LAE Limit Limit 4 Yes
12 – LCDED – Deductible for Deductible 6 No

Loss Classes
13 – LCLIA – Liability for Loss Limit 6 No

Classes
The aggregation category indicates the logical characteristic to which the liability refers; for example, the
reference liability refers to the loss reference, which is stored in the SCHADREF field in table /MSG/RSCHADEN.
You define these aggregation categories in a separate Customizing activity under Treaty NP Data Edit
and Assign Aggregation Categories .
Aggregation Category
● 1 – LOSS – Single Loss

● 2 – EVENT – Loss Event
● 3 – ACCYR – Accounting Year
● 4 – TPER – Treaty Period
● 5 – LREF – Loss Reference
● 6 – LCLS – Loss Class
You edit the limit reference on a detail screen.
Table Reference Field Required Entry Field
/MSG/RSCHADEN SCHADREF Yes
A corresponding aggregation category is also used for the two other liabilities on the LUD screen (the loss
number for liability for a single loss and the loss event number for liability for a loss event).
After you have made the necessary Customizing settings, you must specify how these different liabilities are to
be treated in the non-proportional account for the treaty section. A field called Liability Relationship is provided
on the “NP Liability” tab page for this purpose. For this example, select “Liability with the Highest Rank
(Without Recalculation)”.
In the first part of this example, the non-proportional account is calculated with the mode “Liability” with the
“Highest Rank”. This means that if there is a loss that is also assigned to a loss event, the liability for the loss
event is used for the non-proportional account because it has been assigned the higher rank on the LUD
screen.
An example containing four different losses and their respective FGU postings demonstrates this function in
the FS-RI system in full.
Loss A: EUR 1,300,000
Loss B: EUR 1,700,000

Loss C: EUR 700,000
Loss D: EUR 1,250,000
A loss event is also created, to which loss B and C are assigned.
Furthermore, loss C and D refer to the same loss reference.
Below is a summary of accounts for the non-proportional account.
Loss A
Below Deductible Covered Above Limit
1,000,000 300,000 0
Loss C and D are jointly offset against the liability for the event, although loss C is assigned to a reference. This
reference is overridden by the event assignment, which has a higher rank, with the following result.
1,000,000 1,400,000 0
Loss D runs against the reference liability.
1,000,000 250,000 0
The sum of all four distributed loss accounts is as follows.
3,000,000 1,950,000 0
If you calculate the non-proportional loss for all four losses in succession in FCFS mode, you get the following
result.
Loss Entry Code Amount
A 3100 300,000
B 3100 700,000
C 3100 700,000
C 3100 700,000-
D 3100 950,000
Total 3100 1,950,000

A 7004 1,000,000
B 7004 1,000,000
C 7004 700,000
D 7004 300,000
Total 7004 3,000,000
Total Both Entry Codes 4,950,000 -
The second part of this example demonstrates what happens if “All Applicable Liabilities” is entered in the
Liability Relationship field in the treaty section.
It is important that you enter different data on the LUD tab page because in the case of all applicable liabilities
the excess point of the individual loss is also valid for all three liabilities. In other words, to apply the maximum
liability, the non-proportional account combines the corresponding liability and excess point. As a result, you
must enter a corresponding liability pair for all different aggregation categories. In the case of all applicable
liabilities, the liability pair is always constructed from the liability to be applied at this moment and the amount
available for the lowest limit.
Rank LUD Category Maximum Amount
1 DEDUC – Deductible (Single Loss) 1,000,000
2 LIAB – Liability (Single Loss) 1,000,000
3 LRLIA – Liability for Loss Reference 1,250,000
4 OCLIA – Liability (Loss Event) 1,500,000
Below is a summary of accounts for the non-proportional account in this second example.
Loss A has the same result as before.
1,000,000 300,000 0
Loss B and C are first offset against the individual loss liability; the reference liability is then applied for the
covered amount of the third loss. Finally, both results for the amounts covered are offset against the liability for
the event. More specifically:
Phase 1:
Individual liability – loss B

1,000,000 700,000 0
Individual liability – loss C
700,000 0 0
Phase 2: Reference liability
Loss 3 covered: 0
Phase 3: Loss liability
Loss B and C: Covered: 700,000
This means that, in this example, the application of reference and event liability does not change the covered
amount of the loss.
Again, loss D is first calculated against the individual loss liability.
Individual liability – loss D
1,000,000 250,000 0
The reference liability is then evaluated together with loss C.
Loss C and D covered: 950,000
This again does not change the amount covered.
The result of this type of liability relationship results is as follows.
Total
3,700,000 1,250,000 0
Therefore, the sum is the same FGU amount as in the case of the maximum applicable liability; however, the
amount is distributed differently between “below excess point” and “covered”.
If you calculate the non-proportional account according to the above specifications, the expected result is as
follows.
A 3100 300,000

B 3100 700,000
D 3100 250,000
Total 3100 1,250,000
A 7004 1,000,000
B 7004 1,000,000
C 7004 700,000
D 7004 1,000,000
Total 7004 3,700,000
Total Both Entry Codes 4,950,000
Use
The system uses the entry in the “Currency Handling” field to determine the account currency and the
exchange rate, and then to convert amounts.
Prerequisites
● You have defined the date to be used by the system for currency translation in external Customizing for
Basic System under Default Values Edit Defaults for Accounting . If you have not entered a valuation
date, the system uses the account date.
● If you want to restrict postings to the original currencies existing in the section or currency split, set the
“Currency Check” checkbox in the above Customizing activity.
Features
Determining the Account Currency

The account currency is determined by the entry made in the “Currency Handling” field on the “Partners
Involved” tab page.
● “Share currency”: The system uses the account currency entered in the data for the business partner
share. This applies if the maximum treaty year for the share is before or the same as the accounting year.
● “Account currency”: The system uses the account currency entered in the currency split for the section.
This applies if the maximum treaty year for the share is before or the same as the accounting year.
● “Original currency”: The system uses the original currency.
 Note
If you do not enter a share in the account, the original currency is used.
Currency Conversion
If the original and account currency are not identical, the system translates the amount in original currency into
the account currency. The exchange rate depends on the valuation date. You define how the valuation date is
determined in Customizing. If no Customizing setting has been made for the translation date, the system uses
the account creation date.
In Basic System accounts that come from Risk Manager, the valuation date is left blank. This indicates that the
Risk Manager account was not translated again when transferred to Basic System.
5.3.4 Transfer Exchange Rate
Use
The legal requirements of different accounting principles stipulate that when premium postings are processed
further (for example, unearned premiums are calculated) the exchange rates used are copied to the derived
account.
To fulfill this requirement, you can define for specific accounting functions in certain company codes the
postings for which you want to transfer the translation date.
Features
You can transfer the translation date for currency translations from the source accounts to the target accounts
for the following accounting processes:
Accounting Process Scope

Reserves carried forward The translation date of the underlying opening reserves is
transferred to the corresponding closing reserves, and vice
versa. This applies for the following functions in Basic Sys
tem and Risk Manager:
● The generation of opening and closing reserves using

the following background jobs in Schedule Manger
(transaction SCMA), task list /MSG/FSRI0:
○ Carry Reserves Forward to Target Year (Basic
System) (/MSG/R_A_BATCH_CARRY_FORWARD)
○ Carry Reserves Forward to Target Year (Parallel)
(Basic System) (/MSG/
R_ABR_CARRY_FORWARD_PP)
○ Carry Reserves Forward for Key Date (Basic
System) (/MSG/R_A_BATCH_CFWD_KEYDATE)
○ Carry Reserves Forward for Key Date (Parallel)
(Basic Syst.) (/MSG/
R_A_BATCH_CFWD_KEYDATE_PP)
○ Carry Reserves Forward to Target Year (Risk
Manager) (/MSG/H_FI_P_BATCH_OP_CL_RES)
○ Carry Reserves Forward for Key Date (Risk
Manager) (/MSG/
H_FI_P_BATCH_OP_CL_RES_KD)
● The generation of opening reserves when an account is

released
Release of accounts for participating treaty and connecting The translation date is transferred from the source accounts
treaties to the target accounts only if a rule to this effect has been
defined in Customizing for the target company code. If it has
not, the system re-determines the translation date in the tar
get account.
Retrocession The translation date is transferred from the inward account

to the outward account. This applies for the following func
tions:
● Retrocession (Basic System)

● Retrocession (Risk Manager)
● Treaty calculation rule
● Retrocession adjustment (Basic System)
● Retrocession adjustment (Risk Manager Non-Life)

Unearned premium The translation date is transferred from the premium to the
unearned premium using the following background jobs:
● Calculate Unearned Premiums (Risk Manager) (/MSG/

H_FI_P_BATCH_CARRYFWD)
● Calculate Unearned Premiums (Basic System) (/MSG/

R_A_BATCH_BUE)
Activities
To transfer the translation date, you must define the entry codes in which this rule applies for each accounting
process for which you want to use this function.
 Caution
Note that you can enter only premium entry codes that have been marked as reserves.
 Note
You can also declare a reinstatement entry code as a loss entry code. In this case, you cannot enter a
reinstatement entry code.
You can define entry codes for specific company codes or for all company codes.
 Tip
We recommend that you perform this transfer while the system is running only if all affected premium
postings have been earned in full. Otherwise, subsequent calculations may product incorrect results.
Revaluation of Reserves
When it revalues reserves, the system filters out and ignores entry codes for which settings have been made in
Customizing to transfer the translation date when unearned premiums are calculated and reserves are carried
forward (Basic System or Risk Manager).
You can make the Customizing setting under FS-RI Reinsurance Basic System Accounting Accounting
Principles Settings for Transfer of Exchange Rate .
Release of Accounts for Participating Treaty and Connecting Treaty
When you release accounts for a participating treaty and for connecting treaties, the translation date can be
transferred from the source accounts to the target accounts only if a rule to this effect has been defined in
Customizing for the target company code. You can make the Customizing setting under FS-RI Reinsurance
Basic System Accounting Accounting Principles Settings for Transfer of Exchange Rate by setting the
checkbox Rel. All ("Release Across Company Codes").
Retrocession

You can specify in the target treaty for the retrocession or the treaty calculation rule whether you want to
transfer the translation date from the source account or whether you want to redetermine this date as follows:
1. On the SAP Easy Access screen, call transaction /MSG/R_V2 under Insurance Reinsurance Basic
System Treaty Non-Life .
2. Select a treaty that has the treaty category “Retrocession”.
3. On the Section Header tab page, select a section.
4. Branch to the Section tab page at section level by double-clicking the section.
5. On the Section tab page under Structure Elements, make the corresponding settings in the Currency
Handling During Retro Transfer field.
6. Choose Save.
Unearned Premium
We recommend that you make the following settings in Customizing under FS-RI Reinsurance Basic
System Accounting Accounting Principles Settings for Transfer of Exchange Rate :
● To transfer the exchange rate correctly in Risk Manager when unearned premiums are calculated in a
flexible way, we recommend that you use a combination of the following two checkboxes to ensure that the
translation date produces the correct results:
○ UEP RM ("Flexible Methods for Unearned Premiums (Risk Manager")
○ CFWD BS ("Category of Carryforward (Basic System)")
● To transfer the exchange rate correctly in Basic System when unearned premiums are calculated using
patterns or at the end of a period, we recommend that you use a combination of the following checkboxes
to ensure that the translation date produces the correct results:
○ UEP BS ("Flexible Methods for Unearned Premiums (Basic System)")
○ CFWD RM ("Category of Carryforward (Risk Manager)")
○ Rel. All ("Release Across Company Codes")
To ensure that the correct translation date is forwarded to the current account module, you must make the
corresponding settings on the relevant interface.
5.3.5 Time Handling
The system stores all time units in Coordinated Universal Time (UTC) in the database and uses the local
application server time to display this data.
Use

background jobs.
Features

● Process Treaty Calculation Rules (accounting function: VTGRR)
● Create Opening Reserves in Risk Manager and “Execute Reserve Carryforward (Opening and Closing
Reserves)” in Basic System (accounting function: OPRSV)
functions.
Special Features
Manager functions.
Transfer Group
When accounts are transferred as part of mergers and acquisitions they are summarized according to the
selection period.
If the selection period is “Year to Date” and “Inception to Date”, flexible summarization is used in the treaty
calculation rule.
If the selection period is “Incremental”, the account is not summarized.

Activities
 Note
this purpose.
If a summarization variant has been set to inactive in Customizing, you can no longer assign it to a treaty.
This variant continues to apply to the treaties in which it has been entered.
5.3.7 Use of Parallel Books (Multi-GAAP)
Use
If you want to create more than one financial statement based on different (or the same) accounting principles,
you need to create several sets of books as described below and define the rules for posting to these books.

Prerequisites
1. You have defined the relevant sets of books in external Customizing for Basic System under Accounting
Accounting Principles Edit Accounting Principles .
2. You have assigned the accounting principles to entry codes in Customizing under Accounting
Accounting Principles Assign to Entry Codes . Here, you can also assign all the accounting principles to
one entry code (for example, entry codes for cash items).
3. You have assigned the accounting principles to company codes.
4. You have defined the rules used by the system to generate derived postings in Customizing under
Accounting Accounting Principles Derivation Rules .
You can also enter periods of validity for points 3 and 4; in other words, you can specify that different rules
apply for a specific period of time and also that the system reproduces the summary of accounts after any
change using history management.
Features
When you release an account, the system uses the posting data for the original book to create the posting data
for the derived books.
Selection of Postings for Derivation
Time Shift
When you select the postings to be transferred to a different book, the system observes the time shift defined
in the treaty. So, if you transfer posting data from a book (accounting principle) based on the financial year to a
book based on the accounting year, the difference between the start of the accounting period and the financial
period must match the shift in months defined in the treaty. If you post an entry from a source accounting
principle to a target accounting principle for the same base year, the entry is posted through to the target
accounting principle regardless of the time shift in the treaty.
FAS Classification
You can enter an FAS classification for the derivation rule. This restricts the use of the posting rule. If you do not
enter an FAS classification, the rule applies for all classes.
Company Code
You can restrict the through-posting to postings in a specific company code. If you do not enter a company
code, the system considers all company codes.
Percentage Postings
You can define the amount relevant for the target entry code as a percentage.
 Note
If a single entry code is assigned to different accounting principles, you cannot define derivation rules for
this entry code. This is because the postings for the entry code apply to all books.
For more information, see Derivation Rules [page 366].

Example
Creating Accounting Principles
No. of Accounting Base Year Accounting Principle Name of Accounting Original

Principle Principle
1 Financial year German GAAP German Commercial –

Code (HGB)
2 Financial year U.S. GAAP U.S. Generally Ac –

cepted Accounting
Principles
3 Financial year IAS International Account –

ing Standards (IASB)
4 Accounting year Cedent View Cedent view X
Assigning Accounting Principles to Entry Codes
No. of Accounting Principle Entry Code Name of Entry Code
1 3100 Loss
2 3100 Loss
3 3100 Loss
4 3100 Loss
1 1701 Premium
2 1701 Premium
3 1701 Premium
4 1701 Premium
1 5112 Loss reserve (financial accounting)
4 4112 Statistical loss reserve
Assigning Accounting Principles to Company Codes
Company Code No. of Accounting Principle Name of Accounting Principle
1 U.S. Subsidiary 1 U.S. GAAP
1 U.S. Subsidiary 3 IAS

Company Code No. of Accounting Principle Name of Accounting Principle
2 German Subsidiary 2 German GAAP
2 German Subsidiary 3 IAS
After you have made these basic settings, you can run evaluations based on the different sets of accounting
rules.
Creating Derivation Rules
Company Code Entry Code From Entry Code To FAS Classification Percentage
ISR1 4112 5112 1 100
2501 2509 100
ISR2 2501 2510 1 80
5.3.8 Flexible Ledger Assignment
Use
To map the multi-GAAP functions of SAP General Ledger, you can restrict postings to a group of ledgers.
These ledger groups are used to differentiate between the different accounting principles for regions. A ledger
group can contain one or more ledgers.
Prerequisites
You have defined ledgers and ledger groups in Customizing for Financial Accounting.
Before you can post to different ledgers from the FS-RI system, you must meet the following prerequisites:
● You have defined ledgers in Customizing under Financial Accounting (New) Financial Accounting
Global Settings (New) Ledgers Ledger Define Ledgers for General Ledger Accounting . You have
defined ledger groups in Customizing under Financial Accounting (New) Financial Accounting Global
Settings (New) Ledgers Ledger Define Ledger Group .
● You have activated the use of the ledger group in the FS-RI system in Customizing for FS-RI Reinsurance
under Basic System Default Values Edit Defaults for Accounting by selecting the Use Ledger Group
checkbox.
 Caution
You cannot deactivate the Use Ledger Group checkbox once it has been set and the settings saved.

Features
Relevant Entry Codes
The system generates entries for the relevant entry codes in the work table used to determine the ledger
group. These entries are entered in the posting when the account is released.
Relevant entry codes are relevant for financial accounting, have been assigned to a balance-sheet accounting
principle, and belong to one of the following groups:
● Entry codes for balance-sheet reserves for all actual/estimate indicators (if you are using FS-CD as the
current account system)
● Ledger-specific cash entry codes for all actual/estimate indicators (if you are using FS-CD as the current
account system)
● Other cash entry codes for estimates that are not payable (if you are using FS-CD as the current account
system)
In the case of cash entry codes, the system generates open items in the FS-CD system with a ledger group and
clearing restriction.
If you are using FS-CD as the current account system, the system also generates entries for cash entry codes
as non-payable estimates in the work table used to determine the ledger group.
 Caution
These entry codes were not previously included when the work table was filled. Therefore, if the
Customizing settings are not changed and the work table is filled this may cause errors when the cash
entry codes are processed. In this case, you must adjust the relevant Customizing entries in such a way
that the system can determine a unique ledger group for each combination.
Determination of the Ledger Group
With the introduction of flexible ledger assignment, the Ledger Group field (LDGRP) is added to the posting
table (/MSG/RBU). When you release the account the system fills the field with data for the relevant entry codes
from the work table.
The system does not determine the ledger group for the relevant entry codes for reversed estimates or when
you reverse an account. In this case, the system copies the ledger group, if available, from the original account.
If a ledger group has not been entered in the original posting (meaning that the account originates from the
time before the introduction of flexible ledger assignment or the work table has been changed), the system
also fills the ledger group field from the work table in the case of reversals and reversed estimates.
Customizing
Customizing for Editing Exclusions for Accounting Principles
To determine the ledger group, you can exclude combinations of company code, accounting principle, FAS
classification, entry code, and combination of actual and estimate (in Customizing for FS-RI Reinsurance under
Basic System Accounting Accounting Principles Edit Exclusions for Accounting Principles ).
The following conditions apply:
● The Accounting Principle field is a required entry field. At least one other field must be filled.
● You can enter only accounting principles with the time dimension Financial Year.

● The specified entry codes must be relevant for financial accounting.
● These must be cash entry codes or entry codes for balance-sheet reserves.
● If a field is left empty, the exclusion applies to all values for this field. If the company code is left empty,
combinations involving all company codes are excluded. If the FAS classification is left empty, the exclusion
applies to all FAS classifications and also applies if no FAS classification is used.
Customizing for Assigning Accounting Principles to Company Codes
The column Ledger has been added for assigning accounting principles to company codes. This entry is used
to determine the ledger group (Customizing for FS-RI Reinsurance under Basic System Accounting
Accounting Principles Assign Accounting Principles to Company Codes ). If a ledger has been specified in
the assignment between accounting principle and company code, the system does not include the ledger
entered in Customizing under Accounting Principles Edit Accounting Principles for this combination of
company code and accounting principle when it determines the ledger group.
Customizing for Editing Derivation Rules
To enable automatic offsetting in individual ledger groups, you can enter a negative percentage in the derivation
rule (in Customizing for FS-RI Reinsurance under Basic System Accounting Accounting Principles Edit
Derivation Rules ).
Customizing for Editing Entry Code Definitions
An entry code can be defined as ledger-specific. This enables you to post cash entry codes for a ledger group
(Customizing for FS-RI Reinsurance under Basic System Accounting Entry Code Edit Entry Code
Definitions ).
Activities
Filling the Work Table You have to use the Create Work Table for Ledger Group background job (/MSG/
R_A_FILL_LDGRP) to refill the work table for determining the ledger group every time a relevant setting is
changed:
● FS-RI Reinsurance Basic System Accounting Accounting Principles Edit Exclusions for
Accounting Principles
● FS-RI Reinsurance Basic System Treaty Treaty Classification Edit FAS Classifications
● FS-RI Reinsurance Basic System Forecast and Estimation Edit Combination of Actual and
Estimate

5.3.9 End Date of Financial Year Is Not December 31
Use
If you enter a date other than December 31 as the end of the financial year for the treaty, when it determines
the start and end of the accounting period for the account the system shifts all the dates that relate to the year
(year, half year, four months, and quarter) according to the end date of the financial year.
These dates are always shifted from the accounting year into the future.
Example
End of Accounting Year: March 31
Accounting Year Accounting Period Start of Accounting Period End of Accounting Period
2002 Year April 1, 2002 March 31, 2003
2001 Q2 July 1, 2001 September 30, 2001
2003 January, February January 1, 2003 February 28, 2003
2002 Second four months August 1, 2002 November 30, 2002
Independently of the shifted accounting year end, the Start of Accounting Period, End of Accounting Period,
Accounting Period, and Accounting Year fields are interlinked.
● Case 1: If you enter the accounting year and the accounting period, the system adds the start and end of
the accounting period.
● Case 2: If you enter the start and end of the accounting period, the system adds the accounting year and
the accounting period.
● Case 3: If you enter the accounting period and the start of the accounting period, the system adds the
accounting year and the end of the accounting period.
● Case 4: If you enter the accounting period and the end of the accounting period, the system adds the
accounting year and the start of the accounting period.
● Case 5: If you enter the accounting year only, the system takes the accounting period from the treaty
header and enters the next suitable accounting period start and end dates for the treaty period.
Example:
● Treaty period from June 1, 2002 to December 31, 2006

● End of accounting year: April 30
● Accounting frequency for the treaty: quarterly
If you enter the accounting year 2002, you get the following results.

Accounting Year Accounting Period Start of Accounting Period End of Accounting Period
2002 Q2 September 1, 2002 November 30, 2002
The first quarter is not selected because the start date of the accounting period is May 1, 2002 and this is
before the start of the treaty period.
5.3.10 Display Functions
The FS-RI system offers a range of functions that give you an overview of the accounting flow and the statuses
of funds and payments.
5.3.10.1 Assignment Table
Definition
You use the assignment table to display the source and derived accounts for the account in question, as well as
the target company code.
Use
The overview is useful for navigating between accounts. To do this, double-click the number of the account you
want to open.
To make it easier to process the accounts, the system lets you switch to processing mode after navigating to
accounts in Risk Manager.
However, when you go back the data in the assignment table is not updated automatically.
5.3.10.2 Summary of Accounts
Use
You use this overview screen to display technical and liquid balances, and technical results. These are grouped
in a view according to account, entry code, or loss number.

Features
Selection
By specifying intervals you can enter several accounts at the same time.
If you do not enter a status, the system displays only those accounts that have not been distributed. If you
enter a status, the system displays only accounts with this status.
You can delete the company code from the selection criteria; however the system needs this to retrieve data. If
you do not enter a company code, the system uses a code determined by the following criteria:
1. If you have entered a cedent, the system uses the company code entered for this.
2. If you have entered a business partner, the system uses the company code entered for this.
3. The system uses the current user’s company code.
Display
Postings are grouped according to their entry codes, accounts, and losses.
Directly after the rows for each account, a row is displayed containing the technical and liquid balance, as well
as the technical result for the accounts.
The totals for each company code are then displayed; these include the totals of the technical and liquid
balances, and of the technical result of all the accounts in this entry code.
The last row displays the totals of the technical results and of the technical and liquid balances for all entry
codes and accounts.
If you enter a currency, the system considers only accounts in this currency and displays the result in this
currency. The result is otherwise displayed in the local currency.
You can also aggregate data, set filters, hide columns, and so on, using the standard SAP functions for tables.
5.3.10.3 Total Funds Held
This screen displays all, or a selection of, the funds held for a financial year.
You can also choose to search and display the amounts in the original or account currency; otherwise they are
displayed in the local currency.
An additional totals row is displayed for each fund type.
5.3.10.4 Cash Balance
Definition
On the Actual Cash Balances tab page, the system displays the totals for cash postings that are identical as
regards certain criteria.

Structure
To display the cash balance, open an account and select the Actual Cash Balances tab page.
The system displays the totals of postings, identical as regards certain criteria, in a table. These postings may
also come from different accounts.
To calculate these totals, the postings must have the same:
● Treaty
● Section
● Area
● Business type
● Original and account currency
● Share
Different totals are calculated for each:
● Entry code
● Occurrence year
● Loss
● Recipient
● Broker
● Payment partner
The postings included in the totals must belong to the same accounting year as the original account. In
addition, the totals include only postings in accounts for which the end of the accounting period is before or the
same as the end of the accounting period in the original account.
Changing Cash Balance Postings
You can create new cash balance postings or change existing ones. A change is equivalent to an offsetting
posting to clear the old amount and a posting to enter the new amount.
Since the entries for cash balance postings are totals for similar postings, you cannot delete them. However,
you can change the balance to zero, which has the same effect as deleting it.
5.3.10.5 Policy Exhibit
Use
The policy exhibit is an integrated display and entry screen for accumulated values for an accounting year. It
provides an overview of the statistical posting values entered in the form of a matrix.
The main advantage of the policy exhibit is that the values on this screen are always visible and up-to-date and
do not need to be generated by reports outside of the FS-RI application.
This entry screen was specifically developed for use in life business. Before you use the policy exhibit, you need
to make a number of settings in Customizing that are not entered by default.

Features
You use the policy exhibit to display the evaluations for treaties according to underwriting years and occurrence
years, and accounting units (optional). To call the policy exhibit, switch to the Policy Exhibit tab page in the
account.
Displaying the Values
The system displays the accumulated values for entry codes or calculation bases in a table. You can display
and enter these values for a combination of underwriting year, occurrence year, and accounting unit (selection
criteria). The revenue period is always taken to be the accounting period for the account. Values can be entered
in the leading currency only.
The policy exhibit screen comprises, at most, six user-defined columns; the user can determine the number of
rows.
● To enter new criteria, choose .
● To calculate and display the values for the selected criteria, choose . The system displays the values,
locks the selection criteria, and unlocks the table so that you can edit the values.
Editing the Values
In the table you can change the fields for which an entry code is defined, or enter new values. When you save
data or exit the policy exhibit screen, the system compares the changes to the original data and generates
postings for the differences. During this process, the system locks the entries for the underwriting year,
occurrence year, and accounting unit.
Constraints
● You can enter values in the leading currency only.

● You can display and enter values for the respective treaty classes only.
Definitions
● Brought forward value: This is the accumulated value of all postings created and released so far for this
treaty, the entry codes for which are stored in the respective calculation base.
● Carry forward value: This consists of the current value brought forward and the current postings for this
account. At least one calculation base is provided for this value, the entry codes for which are
accumulated.
5.3.10.6 Document Creation
Reinsurance Account Statement and Current Account Statement
You can use the Billing/Account Statement [page 467] function to print RI account data, current account data,
reserves data, and fund data. Before you print you can display a preview of the data on the screen. You can use
selection parameters to restrict the volume of data printed.

Bordereau Creation
You can use the Bordereau Creation [page 475] function to enter a predefined amount of account data into a
bordereau.
You can create temporary and final bordereaux.
The “Repeat Printout” and “Reset” functions are available for final bordereaux.
5.3.10.7 Reinsurance-Specific View of Accounts
Use
You can call the FS-CD account view using a separate transaction with a reinsurance-specific selection screen.
Features
You use transaction FPL9 to select FS-CD accounts.
You can also make this selection using FS-RI-specific selection parameters in transaction /MSG/
I_DISP_ACBAL.
The selection parameters include the following criteria:
● Start of Billing Period

● End of Billing Period
● Payment Grouping
● Partner for Payment
● Account Recipient
● Address of Account Recipient
Include Own Fields on Detail Screens
You can add your own selection subscreens to enhance the selection screen for the view of accounts. You find
these settings in Customizing ( SAP Insurance Collections/Disbursements Basic Functions Postings
and Documents Document Screen Preparations Include Own Fields in Detail Screens ).
5.4 Forecast and Estimation
In the FS-RI system you can enter forecasts and estimated accounts for a treaty relationship if the final
accounts are not yet available.

You can define a set of rules at treaty level and then execute the process as a background job. The amounts,
rules, and development patterns defined in these rules determine the methodology for creating forecasts and
estimated accounts, which may also be based on existing accounts and postings.
The FS-RI processing logic distinguishes between a forecast and an estimation: A reversal account is generated
for estimates, but not for forecasts. In this context, reversal means that the system automatically creates an
offsetting posting in a separate reversal account to clear the respective amount in the estimate account
following a triggering event (such as arrival of the final account that replaces the estimate).
You can also define a set of rules for one or more groups, or define global rules for certain treaty section
attributes in a Customizing dialog.
When you run the background job for a treaty, the system then applies the global rules in Customizing and for
the groups assigned to the treaty, as well as the rules defined for the treaty itself.
To simplify the process for entering a set of rules in the treaty or for a group, you can define templates in
Customizing. These can then be imported to the relevant maintenance dialog using a corresponding button,
and you only have to enter values for the fields that do not support default settings.
You can make the respective settings in Customizing only if you have the appropriate authorizations.
5.4.1 Development Pattern
Definition
A development pattern is a curve consisting of percentage values, which can be used to calculate future
business development.
Use
You use the development pattern to create forecasts and estimations for treaties, for example for premium
development or late losses.
Structure
In a development pattern, a percentage value is assigned to a time period. Depending on the type of
calculation, the system multiplies this value by a base value to obtain a resulting value for the assigned period.
If you perform a calculation for a period for which no percentage value is entered in the development pattern,
this value is defined by the prolongation type.
You define the prolongation type in internal Customizing for Basic System under Forecast and Estimation
Edit Prolongation Type .
Global Development Pattern

A global development pattern is a curve that you use several times, for example over the course of an unearned
premium. You define global development patterns in external Customizing for Basic System under Forecast
and Estimation Edit Development Patterns .
Local Development Pattern
If you want to use a specific development pattern in a treaty, you can define this in the treaty on the “Local
Development Patterns” tab page at forecast and estimation level. If you want to use a global development
pattern as the basis for this local development pattern, choose Localize Development Patterns. If you select this
option, the system does not transfer the changes made to this pattern to the pattern in Customizing.
5.4.2 Forecast and Estimation Rule
Definition
A forecast and estimation rule forms the basis for every forecast or estimation calculation. In this rule, you
enter the data to be used by the system as a basis for the forecast or estimation and also specify how the
system is to analyze this data in the calculation.
Structure
You can enter forecast and estimation rules in three different ways:
● In external Customizing for Basic System under Forecast and Estimation Maintain Global Parameters
for Forecast and Estimation .
● You can choose rules from Customizing directly in the forecast and estimated account.
● In the treaty group (on the Forecast and Estimation tab page at treaty group header level).
● Rules in the treaty group apply to all treaties in the group.
● In the treaty (on the Forecast and Estimation tab page at treaty header level).
In the header data you enter the periods and sections or treaties for which the rule applies. When you double-
click the header data row, the individual details of the rule appear. This is where you can describe the rule in
more detail. If you do not enter the validity area in full in the header data for the rule at treaty level, you can do
this one level lower. For more information, see Distribution of Values to Periods and Sections in the Treaty [page
542].
 Note
The system passes data for a rule in an assigned group on to a treaty only if you have entered all the rules
defined in this treaty in the header data for one section and one occurrence, underwriting, and accounting
period.
If at least one rule in the treaty is only specified by distribution to underwriting years and distribution to
sections, group rules do not apply for this treaty.
Level of Detail of Forecast and Estimation Postings

In the “Type of Detail” column on the “Policy Sections” tab page, you specify to what extent you want the
Forecast and Estimation background job [page 429] to include individual detailed structural characteristics. For
more information and an example of this, see Level of Detail of Postings [page 417].
Interlinked Forecast and Estimation Rules
If you perform an interlinked forecast and estimation, where the input data for a forecast or estimation
depends on the result of a different forecast or estimation, you must enter the correct sequence for processing
the rules. For this reason, you assign a rank number to each rule. The rank numbers apply across all levels. This
means that the system first finds all the applicable rules at Customizing, group, and treaty level and then uses
the rank numbers for these rules (regardless of the level) to determine the processing sequence.
To ensure that a rule at one level is not given the same rank number as a rule at another level, you must assign
the rank numbers from the number range intervals defined in Customizing.
You define these number range intervals in internal Customizing for Basic System under Forecast and
Estimation Edit Number Range Interval .
5.4.2.1 Defining Distribution Details
Context
It may be the case that the header data for the forecast and estimation rule does not adequately describe how
the base value for calculating forecasts and estimations is distributed to underwriting dates, occurrence dates,
and treaty sections. If so, you must describe the distribution in more detail.
This applies if one of the following conditions is met:
● At least one time unit is defined as an interval; this means that the end date field contains an entry.
● There is no entry in the Section field.
Procedure
1. At forecast and estimation level in the treaty, go to the Distribution Details tab page.
2. Enter the underwriting dates and occurrence dates to which the base amount for forecast or estimation is
to be distributed within the period defined in the header data. Enter the corresponding distribution
percentages.
3. Double-click an underwriting year and an occurrence year entry. The Section Distribution tab page
appears.
4. Enter the sections to which the proportional base amount from the underwriting year and occurrence year
entry you have just created is to be distributed. Enter the corresponding distribution percentages.

 Note
The Distribution Details tab page is hidden if the distribution is already defined in the header; in other
words, neither of the abovementioned conditions is met.
Results
During calculation, the system distributes the amounts entered in the forecast and estimation rules in the
header, according to your specifications.
5.4.2.2 Level of Detail of Postings
Use
If you do not enter a level of detail for forecast and estimation rules, the Forecast and Estimation background
job posts all the results to the main structural characteristics.
If you want to post the results calculated from the forecast and estimation to the individual structural
characteristics, select the type of detail Adjustment Postings/Delta Postings or Pro Rata. The system includes
the structural characteristics Class of Business, Area, Line of Business, Business Type, and Accounting Unit for
the detailed posting.
Prerequisites
To enter a higher level of detail for the forecast and estimation:
● The comparison method must be Every Difference.

● You must not have entered a deduction base.
● You must have entered a percentage calculation base. You can enter details for all three possible
percentages:
○ Explicit entry of a percentage
○ Storage of a development pattern
○ Definition of a numerator and denominator calculation base (the numerator and denominator
calculation base is always evaluated using all the posting data, independent of the type of detail)
Features
No Detail

If you do not enter a value, the forecast and estimation does not distribute data and posts the result values to
the main structural characteristics.
Adjustment Postings (Delta Posting)
If the type of detail is Adjustment Postings, the structural characteristics are posted proportionally depending
on when they appeared.
The forecast and estimation balances existing postings to the target entry code using the target value of the
target entry code that is taken from the calculation base for the combination of structural characteristics.
Example 1 – Adjustment Postings
Class of Area Business Line of Account Actual Calcula Target Internal Internal Posting
Business Type Business ing Unit tion (30% of 1 (Re 2 (Target (Target-
Base Calcula verse Ac Value) Actual)
tion tual)
Case)
GL DE Direct Private Architect 30.00 100.00 30.00 -30.00 30.00 0.00
GL DE Indirect Private Architect 20.00 0.00 0.00 -20.00 0.00 -20.00
GL DE Direct Private Dentist 40.00 300.00 90.00 -40.00 90.00 50.00
GL DE Indirect Private Dentist 40.00 160.00 48.00 -40.00 48.00 8.00
GL DE Direct Private Director 20.00 200.00 60.00 -20.00 60.00 40.00
GL DE Indirect Private Director 30.00 120.00 36.00 -30.00 36.00 6.00
Totals 180.00 264.00 84.00
Actual 264.00
GL DE Direct Private Architect 30.00 100.00 30.00 -30.00 30.00 0.00 GL DE Indirect Private Architect 20.00
0.00 0.00 -20.00 0.00 -20.00 GL DE Direct Private Dentist 40.00 300.00 90.00 -40.00 90.00 50.00 GL DE
Indirect Private Dentist 40.00 160.00 48.00 -40.00 48.00 8.00 GL DE Direct Private Director 20.00 200.00
60.00 -20.00 60.00 40.00 GL DE Indirect Private Director 30.00 120.00 36.00 -30.00 36.00 6.00 Totals
180.00 264.00 84.00 Actual: 264.00
Pro Rata
If the type of detail is Pro Rata, the system not only includes the historical values from the calculation base in
the estimated distribution but also any existing actual values from the period for which the forecast and
estimation was created. The following formula applies to the postings to the individual structural
characteristics.
Variables
A = amount of the target posting to the individual structural characteristic
T = target value calculated for the combination of structural characteristics (for example, this can be a
percentage multiplied by the calculation base used as the estimation basis for the current estimated period
and usually calculated using the actual results from earlier periods)

I = sum of the postings to the combination of structural characteristics that have already been made in the
current period
ΣT = sum of all target postings across all combinations of structural characteristics
ΣI = sum of all actual postings across all combinations of structural characteristics
Formula
A = (T / ΣT) (ΣT – ΣI)
Example 2 – Pro Rata
Class of Area Business Line of Account Calcula Actual (I) Target Posting Actual Af
Business Type Business ing Unit tion Base (30%) (T) (A) ter Execu
tion of
Function
GL DE Direct Private Architect 100.00 30.00 30.00 9.55 39.55
GL DE Indirect Private Architect 0.00 20.00 0.00 0.00 20.00
GL DE Direct Private Dentist 300.00 40.00 90.00 28.64 68.64
GL DE Indirect Private Dentist 160.00 40.00 48.00 15.27 55.27
GL DE Direct Private Director 200.00 20.00 60.00 19.09 39.09
GL DE Indirect Private Director 120.00 30.00 36.00 11.45 41.45
Totals 180.00 264.00 84.00 264.00
Delta 84.00
Delta % 0.3182
5.4.3 Editing Forecast and Estimation Data
Delete forecast and estimation header On the Forecast and Estimation tab When you delete a forecast and estima
page at treaty header level, mark the tion header and have activated the
clearing routine, the system generates
entry you wish to delete and select
offsetting postings for all the postings
or select Edit Delete Entry .
belonging to this header. You make the
relevant settings in external Customiz
ing for Basic System under Prognosis
and Estimation Maintain Clearing
Routine .

5.4.4 Relevant Parts of the Treaty Dialog
In the treaty dialog you can enter a set of rules for creating forecasted and estimated accounts once you have
created a period and a corresponding section. You make the entries at treaty period level on the Forecast and
Estimation tab page. On the overview screen, you first enter the header data for the set of rules. You need to
enter values in the following fields.
Section
In this field you enter the number of the section to which the set of rules applies.
Occurrence Date
The occurrence date is used in conjunction with the section number and other dates (underwriting date and
start of accounting period) to enable a unique assignment of the set of rules for generating forecasted and
estimated accounts for a treaty period.
In addition, this occurrence date is transferred to the generated forecast and estimation posting.
Underwriting Date
The underwriting date is used in conjunction with the section number and other dates (occurrence date and
start of accounting period) to enable a unique assignment of the set of rules for generating forecasted and
estimated accounts for a treaty period.
In addition, this underwriting date is transferred to the generated forecast and estimation posting.
Start of Accounting Period
This date is used in conjunction with the section number and other dates (underwriting and occurrence date)
to enable a unique assignment of the set of rules for generating forecasted and estimated accounts for a treaty
period.
The start date of the accounting period must match the accounting frequency and the end of the financial year
entered in the treaty header. The accounting period in the generated forecast and estimation posting is taken
from the selection screen for the background job.
The system fills the remaining fields in the header dialog automatically (at the latest when you save your
entries).
Once you have entered all these successfully, you can navigate to the detail screen by selecting a line and
clicking the magnifying glass (Choose Row). This is where you enter the actual set of rules.
The detail screen contains the following fields.
Rank
The rank defines the processing sequence. Each rank must be unique, in other words you must use a rank
number once only in each set of entries.
The processing sequence is important because of the possible interdependencies. For example, the result of
the calculation for a given rank may affect a subsequent calculation with a higher rank.
End Date of Accounting Period
The end date of the accounting period is used to establish whether or not the rule entry needs to be calculated.
For example, if a rule is to be calculated at a point in time after the end of the accounting period, it is excluded
from processing.

The end date of the accounting period is also used to determine the set of postings to which the calculation
bases defined in the rule are applied.
You can enter only values that match the accounting frequency and the end date of the financial year for the
treaty (the same applies for the start date of the accounting period).
Accounting Unit
In this field you can select one of the global or local accounting units assigned to the treaty.
If you enter an accounting unit, the system applies the rule entry only to postings that have the same
accounting unit value.
If you do not enter an accounting unit, and the treaty is a life treaty, the rule entry is applied separately to each
accounting unit. In other words, each rule actually comprises several rules – one for each of the accounting
units used in the corresponding treaty section.
If you do not enter an accounting unit and the treaty is a non-life treaty, the postings are processed without
taking the accounting unit value of the respective posting into account.
If the background job creates a posting for a rule entry, the accounting unit values are based on the accounting
unit entered in the rule. If you do not enter an accounting unit for a non-life treaty, no accounting unit values are
stored in the resulting posting.
Use
You can use the Usage checkbox to group the entries for a set of rules. When you run the background job, the
system then processes only the entries that have the same usage setting as the one you enter on the selection
screen for the background job.
The Usage checkbox also defines the actual/estimate indicator for the generated account.
Entry Code
In this field you enter the entry code for the resulting posting for the rule entry.
Reference Period
The reference period indicates when the rule is calculated. There are three possible settings.
If the reference period is set to Financial Year, the rule is always calculated when the calculation date of the
background job falls within a technically open financial year. Otherwise, no calculation is performed.
If the reference period is set to Period, the rule is calculated when the calculation date for the background job
falls within the treaty period, or when rule in the treaty has been changed since the last background job.
If the reference period is set to Accounting Year, the rule is calculated when the accounting period entered on
the selection screen for the background job overlaps with the accounting period for the rule, which is based on
the start and end dates for the accounting period.
Currency
In this field you can enter the currency in which the system saves the generated account for the rule. If you
leave the field empty, the system uses the leading currency for the respective treaty section for the forecast.
Exchange Rate Type
If you enter a currency, you must also enter the exchange rate type.
Amount

If you want to generate a resulting posting with a specific amount, you can enter the desired amount directly in
the rule.
You can enter only one amount or one percentage, only the development pattern, or only the numerator and
denominator calculation base.
Percentage
This percentage is used in conjunction with the mandatory calculation base entered to calculate a value for
generating the resulting posting.
Calculation Base: Numerator
Instead of entering a percentage, you can calculate the rate by dividing one calculation base by another. This
field contains the calculation base for the numerator.
Calculation Base: Denominator
Instead of entering a percentage, you can calculate the rate by dividing one calculation base by another. This
field contains the calculation base for the denominator.
If the result of the denominator calculation base is 0, the system does not use the calculation rule for further
processing.
Development Pattern
In Customizing for Basic System under Forecast and Estimation Edit Development Patterns , you can
define how percentage values develop over time in a development pattern. This development pattern can then
be entered in the rule definition.
The calculation date is based on the last day of the accounting period entered on the selection screen. The
start date depends on the reference period.
If the reference period is the accounting year, the start date is the start date of the accounting period. If the
reference period is the financial year or period, the start date is the start date of the treaty period.
Reference Year
The reference year restricts the time frame of postings to which the calculation bases in a rule are applied:
financial year: only postings in the accounting year of the background job; previous year: only postings from the
previous year; field is empty: all postings for which the end date of the accounting period is not after the
calculation date of the background job.
Comparative Method
The system applies the calculation base and then multiplies the result by a percentage value (either a value
from a development pattern or a value entered directly). This produces a value for the calculation base (CB).
The system also calculates the deduction base (DB). These two values are then offset against each other on
the basis of the comparative method. The following settings are possible:
● Every difference
The result of CB – DB is used to generate the resulting posting.
● Positive difference
The maximum of CB – DB and 0 is used to generate the resulting posting.
● Negative difference
The minimum of CB – DB and 0 is used to generate the resulting posting.
● Maximum
The greater of the two amounts CB and DB is used.

● Minimum
The lesser of the two amounts CB and DB is used.
Calculation Base
Like the other calculation bases, this calculation base defines a collection of entry codes used to calculate a
value on the basis of selected postings. This value is then multiplied by the percentage defined in the rule
(either directly, or using a development pattern) and then processed further.
Deduction Base
This is the calculation base that is offset against the preliminary estimated result of “calculation base x
percentage” using the respective comparative method.
Filter for Calculation Base – Numerator
In external Customizing for Basic System under Forecast and Estimation Edit Combination of Actual and
Estimate , you can define a collection (combination) of actual/estimate indicators for each calculation base.
When you apply a calculation base, the system then includes only technical accounts and postings with actual/
estimate indicators that are included in the combination of actual/estimate indicators defined for the
respective calculation base.
In this field you define the combination of actual/estimate indicators for the numerator calculation base.
Filter for Calculation Base – Denominator
When you apply a calculation base, the system includes only those accounts and postings with actual/estimate
indicators that are included in the combination of actual/estimate indicators defined for the respective
calculation base.
In this field you define the combination of actual/estimate indicators for the denominator calculation base.
Filter for Calculation Base
calculation base.
In this field you define the combination of actual/estimate indicators for the calculation base.
Filter for Offset Calculation Base
calculation base.
In this field you define the combination of actual/estimate indicators for the offset calculation base.
5.4.4.1 Creation of a Forecast and Estimation Overview
Use
You use this function to obtain an overview of the result of the calculation of your forecast or estimation without
having to make corresponding postings.

Activities
At forecast and estimation level in the treaty, select the Overview tab page.
The system calculates the forecasted or estimated values for all detail items based on the valid rules for the
treaty.
Double-click an item to obtain its individual details.
5.4.5 Group Dialog
You can define a set of rules for creating forecasted and estimated accounts and corresponding postings for a
whole group, and not just for individual treaties.
However, the group must belong to a group category that is suitable for entering forecasts and estimations. You
determine this by setting the relevant checkbox in the Customizing activity for group categories.
The fields for the group are identical to the corresponding fields in the treaty dialog. The only difference is that
the dialog for the group is not split into a header and detail screen.
If a forecast is entered for a group, the values entered are applied to the treaty sections assigned to the group
when the background job is run for the corresponding treaty.
The standard FS-RI system does not include a function for distributing amounts from the forecast and
estimation dialog. However, you can use a Business Add-In (BAdI) to implement your own customer-specific
requirements.
For an overview of the overall process for a group forecast or estimation, see the corresponding examples.
5.4.6 Processing of Accounting Units in Forecast and

Estimation
Use
You can restrict a forecast or estimation to postings within certain accounting units.
Features
Non-Life Treaty
If you have not specified an accounting unit for forecast and estimation rules and the treaty is a non-life treaty,
the system processes postings irrespective of the accounting unit value of the respective posting.
If, after processing the forecast and estimation rule, the system generates postings in a background job, the
accounting unit values are based on the accounting units specified in the rule. If you have not specified
accounting units for the rule, the system stores the posting without accounting units.

Life Treaty
In a life treaty, the system assigns to the target posting the accounting unit to which the respective calculation
bases were applied.
Example
You have a quota share treaty and have assigned two global accounting units to a section in this treaty.
This treaty contains three forecast rules; two for each accounting unit and one without a specified accounting
unit. Each of these is a year-end forecast with the following details.
Details for Forecast Rule
Rank Amount Percentage Reference Year Comparative Accounting Unit

Method
3 1400 0 None Every difference
You then run the background job for forecast and estimation with the following settings.
Accounting Period: YEAR
Usage: Y, F
Accounting Year: 2000
Financial Year: 2300
Month: 03
Detailed Log: Yes
The system generates an account with three loss payment postings for the underwriting and occurrence year
2000.
Amount for unspecified accounting unit: 1400
5.4.7 Customizing for Forecast and Estimation
To create or generate a meaningful forecast or estimation, you need to make various Customizing settings in a
predefined order.
This section describes all the relevant internal and external Customizing settings in the logical sequence. Each
Customizing activity builds upon those before it.

You can make the respective settings in Customizing only if you have the appropriate authorizations.
Internal Customizing
You can make settings in internal Customizing for Basic System under Forecast and Estimation in the following
Customizing activities:
● Define Actual/Estimate Indicator

● Edit Reversal Methods for Estimated Accounts
● Edit Development Pattern Categories
● Edit Comparative Methods
● Edit Forecast Level
● Edit Number Range Interval
● Edit Prolongation Type
Edit Reversal Methods for Estimated Accounts
You first have to define the reversal method. There are only two possible reversal methods: automatic reversal
in the following year and reversal after receipt of the final account. In this context, reversal means an offsetting
posting to clear estimated accounts (actual/estimate indicator set).
Define Actual/Estimate Indicator
Once you have defined the reversal method, you can define the actual/estimate indicator, which is a key
component of the prognosis and estimation.
There are essentially four different types of actual/estimate indicator: final account, forecast, estimate, and
reversed estimate. The following conventions apply.
The indicator in the first line of the maintenance dialog should always be “Final Account”. You can use this
indicator once only.
If you have entered values in the “Reversal Method” and “Reversal Attribute” fields, the actual/estimate
indicator relates to an estimate. These two entries control the method that is used to reverse this estimate, and
the actual/estimate indicator that is assigned to the reversal. Therefore, the actual/estimate indicators that
appear in the “Reversal Attribute” column are those that are used for reversals.
Apart from estimates, all the other types of actual/estimate indicator must not have entries in the “Reversal
Method” and “Reversal Attribute” fields.
You can define several different estimates by entering different values for the other actual/estimate indicator
attributes.
In the “Transfer” column for an actual/estimate indicator you can specify whether an account with this actual/
estimate indicator is transferred to the subledger accounting system. If you set this indicator, you can use the
current account clearing checkbox (“CA Cl.Ind.”) to control whether the open item created in the subledger
accounting system is cleared.
You can then define the actual/estimate indicators that relate to forecasts. These do not belong to any of the
other three actual/estimate indicator groups: The actual/estimate indicator is not the first entry in the
maintenance dialog, you have not entered values in the “Reversal Method” and “Reversal Attribute” fields, and
the actual/estimate indicator does not appear in the “Reversal Attribute” column.
Edit Comparative Methods

When you create a set of estimation parameters in a treaty or group, the system evaluates calculation bases
and offsetting calculation bases and offsets them against each other. In this Customizing activity, you define
the comparative methods and enter corresponding texts.
There are a total of five comparative methods, each of which must be maintained in this activity.
Edit Development Pattern Categories
When you create a set of estimation parameters in a treaty or group, you enter a reference period that indicates
when the rule is calculated. There are three possible settings: “Accounting Year”, “Financial Year”, and “Period”.
Edit Forecast Level
In this Customizing activity, you specify the forecast levels.
Edit Number Range Interval
In this Customizing activity, you define the number intervals for the ranks for the rules. For more information,
see Prognosis and Estimation Rule [page 415].
Edit Prolongation Type
In this Customizing activity, you define the prolongation types.
External Customizing
Once you have made all the internal Customizing settings, you can move on to external Customizing. You can
make settings in the following Customizing activities under Forecast and Estimation:
● Edit Development Patterns

● Maintain Global Parameters for Forecast and Estimation
● Edit Forecast and Estimation Templates
● Edit Combination of Actual and Estimate
● Activate Clearing Routine
● Edit Usages for Estimation
The Customizing activity Default Values Edit Defaults for Accounting (Calculation Fields) is also relevant.
Edit Usages for Estimation
You first have to define the usage for the estimation.
When you define a set of estimation parameters in a treaty or group, you must enter a usage for the estimation
in this Customizing activity
If you process the forecasts or estimation as a background job, you specify the usage on the selection screen
for the job.
The background job then only applies the set of estimation parameters that have the same usage. In this way,
you can process a certain number of estimation parameters for a treaty.
On the maintenance dialog for this Customizing activity you enter a short and long text and specify the actual/
estimate indicator (estimation category) that applies for the usage in question. The generated account that
contains the posting resulting from a set of estimation parameters is assigned the actual/estimate indicator
from the usage.

The “Estimate” checkbox is not really necessary on this screen, since the actual/estimate indicator tells you
whether the entry relates to an estimate. This checkbox originates from an earlier release, and has been
retained to ensure data consistency.
Edit Combination of Actual and Estimate
You then have to define the combination of actual and estimate.
The dialog is split into two parts. You first enter a key and text in a header entry, and then branch to a subdialog
to enter a certain set of actual/estimate indicators.
Therefore, each combination represents a collection of actual/estimate indicators.
The calculation bases used in a set of estimation parameters can be assigned a combination of actual/
estimates as a filter.
This calculation base is then applied only to accounts and postings with actual/estimate indicators that are
included in the combination. When conditions are processed in a background job (for example, result-
dependent conditions), you must enter a combination of actual/estimate on the selection screen for the job.
This means that the condition is only processed for accounts that have one of the actual/estimate indicators
defined in the combination.
When you calculate the result-dependent conditions, you must also specify the actual/estimate indicator for
the generated account.
Edit Development Patterns
When you define a set of estimation parameters in a treaty, you can enter a development pattern. The
percentage values for this development pattern are then used to determine the calculation base. You define the
development pattern in a two-step Customizing activity.
The time scale for the development pattern begins at the start of the treaty period and is based on the
accounting frequency.
There is also a checkbox for distributive postings (“Dist.Post.”). If you set this checkbox, the evaluation of the
corresponding development pattern triggers distributive postings. In other words, the current curve value is
used to generate a posting, which is only compared to other postings within the accounting period for the
respective treaty section. If you do not set this checkbox, the development pattern is processed using
cumulative logic.
Maintain Global Parameters for Forecast and Estimation
When you edit global parameters for forecast and estimation you should note that the global development
pattern only takes effect if the treaty does not contain a set of estimation parameters for these attributes when
the background job is run. You can override the global development pattern by a group forecast.
Edit Forecast and Estimation Templates
You edit forecast and estimation templates in the subdialog in the same way as when you create a set of
estimation parameters in a treaty or group. You can then import this template into a treaty or group by using a
corresponding pushbutton, and save it.
You first define the desired template in the header data for the treaty.
You can then import the template by choosing the “Load Estimate Template” pushbutton on the detail screen
for creating a set of estimation parameters.
Activate Clearing Routine

In this Customizing activity, you activate or deactivate the clearing routine. For more information, see Editing
Forecast and Estimation Data [page 419].
Edit Defaults for Accounting (Calculation Fields)
When the final account is entered, you need to define the accounting periods in which the final account
replaces the estimated accounts.
You make this setting using the Cumulative Reversal checkbox in external Customizing for Basic System under
Default Values Edit Defaults for Accounting (Calculation Fields) .
If you set this checkbox, when estimated accounts are replaced (reversed) by a final account, the system
reverses only those accounts in which the end of the accounting period is before or the same as that of the final
account.
If you do not set this checkbox, the system reverses only estimated accounts with accounting periods that fall
within the accounting period of the account triggering the reversal.
5.4.8 Forecast and Estimation (Basic System)
Use
The technical name of the background job is /MSG/R_ABR_EARN_CURVE.
This background job creates estimated accounts for the treaties corresponding to the selection criteria.
Features
Level of Detail of Forecast and Estimation
The level of detail of the forecast and estimation determines whether the background job posts to individual
structural characteristics or to each main structural characteristic. You enter the level of detail on the different
forecast and estimation screens (treaty, group, Customizing) on the Policy Sections tab page.
Parallel Processing
While the system is processing the relevant objects, it does not lock the other objects contained in the same
table. This means you can run several background jobs at the same time and work with objects not being
processed while the background job is running.
Error Tolerance
If an error occurs while the background job is processing objects, the system records this error in the log; the
background job is not interrupted.
5.4.9 Examples
The following examples demonstrate the effect of the forecasts and estimation rules.

5.4.9.1 Required Customizing Settings for These Examples
Before you can perform the examples described in the following sections, you must make the following settings
in Customizing.
For general information about Customizing, see Customizing for Forecast and Estimation [page 425] and the
documentation for the individual activities in the system.
General Settings
Entry Codes
Customizing for Basic System under Accounting Entry Code Edit Entry Code Definitions
Entry Code Name Plus/Minus Sign for Type of Entry Code All Checkboxes Set
Entry Code Except Carryforward
and Inactive
1701 Premium (+) 1 1 Yes
1711 Estimated premium 1 1 Yes
1730 Premium refund 2 1 Yes
1750 Gross net premium in 1 1 Yes

come (GNPI)
2011 Commission 2 1 Yes
2101 Provisional commis 2 1 Yes

sion
2111 Estimated commission 2 1 Yes
2301 Handling costs 2 1 Yes
2400 Brokerage 2 1 Yes
2700 Profit commission 2 1 Yes
3100 Loss payment 2 2 Yes
3200 Annuity payment 2 2 Yes
3303 Loss expenses 2 2 Yes
TE01 Technical profit 1 1 Yes
TV01 Technical loss 2 1 Yes

Calculation Bases
Customizing for Basic System under Accounting Entry Code Edit Calculation Bases and Rules
Calculation Base Name Calculation Rules
PE01 Forecast and estimation (GNPI) 100% x entry code 1750
PE02 Forecast and estimation (premium after 100% x entry code 1701
advance payment)
PE03 Forecast and estimation (premium after 100% x entry code 1701 x -1
advance payment)
PE05 Forecast and estimation (estimated 100% x entry code 1711

premium)
PE06 Forecast and estimation (loss participa 100% x entry code 3100 x -1
tion)
PE07 Forecast and estimation 100% x entry code 3100
PE08 Forecast and estimation (profit com 100% x entry code TE01 x -1
mission)
PE09 Forecast and estimation (technical re 100% x entry code 1711
sult)
100% x entry code 3100
PE10 Forecast and estimation (loss participa 100% x entry code TV01 x -1
tion)
PE12 Forecast and estimation (calculation 100% x entry code 1701

base denominator)

base numerator)

base for divisor)
20% x entry code 1730
PE15 Forecast and estimation (estimated 100% x entry code 1711

premium)
PE16 Forecast and estimation (estimated 100% x entry code 1711 x -1

premium (-))
PE18 Forecast and estimation (GNPI after ad 100% x entry code 1750 x -1
vance payment)
Defaults for Accounting (Calculation Fields)
You must set the Cumulative Reversal checkbox in this Customizing activity.

Settings for Forecast and Estimation
You find the following Customizing activities under Forecast and Estimation.
Edit Development Patterns
Development Pattern Name of Development Pat Name Accounting Frequency

tern
BSP9 BSP9 Test for Release 4.64 3
ESTP ESTP Estimated premiums 12
FOREC FOREC Test for forecast 1
Percentages for Estimation Data
Estimation Data for Development Pattern BSP9 (Test)
Sequence Number Rank Percentage
1 1 5.000000000
2 2 15.000000000
3 3 18.000000000
4 4 5.555000000
5 5 6.666000000
6 6 7.777000000
7 7 45.000000000
8 8 58.000000000
9 9 80.000000000
10 10 100.000000000
Estimation Data for Development Pattern ESTP (Estimated Premiums)
1 1 5
2 2 10
3 3 18

4 4 22
5 5 30
6 6 50
7 7 55
8 8 70
9 9 80
10 10 90
11 11 95
12 12 100
Estimation Data for Development Pattern FOREC (Forecast)
1 1 10
2 2 20
3 3 30
4 4 40
5 5 50
6 6 60
7 7 70
8 8 80
9 9 90
10 10 100
Maintain Global Parameters for Forecast and Estimation

Use Rank Class Line Area Treaty Na Mode Entry Refer Devel Refer Com Calcu De
of of Cate ture Code ence op ence para lation duc
Busi Busi gory of Pe ment Year tive Base tion
ness ness Treaty riod Pat Meth Base
Num tern od
ber
10 11 0027 DE 1 P A 1701 3 3 3 PE01
21 0027 DE 1 P A 3100 3 3 3 PE18
31 0027 DE 1 P A 3200 3 3 3 PE18
You do not need to make any entries in columns not listed here.
Edit Forecast and Estimation Templates
Template Template Name
10 DOCU F&E documentation
Edit Combination of Actual and Estimate
Combination of Actual/ Combination of Actual/ Name Inactive

Estimate Estimate
1 FINAL Estimate indicator used for

final data
2 FOREC Estimate indicator used for

forecast
3 EST1 Estimate indicator for esti

mate - affordable
4 EST2 Estimate indicator for esti

mate – not affordable
Actual/Estimate Indicator for Entry 1
Estimate 1: / Inactive: No

Edit Usages for Estimation
Use Use Name Create as Esti Estimate Filter Inactive

mate
10 Y, F Year-end fore 2
cast
11 Y, E1 Year-end esti X 3
mate – payable
5.4.9.2 Creating Dependent Forecasts Using Amounts and

Calculation Bases
Use
This example demonstrates how you can enter an amount as a rule entry and then define other dependent rule
entries to produce corresponding generated accounts.
This enables you to create a complete forecast for a treaty period on the basis of key data, without being
dependent on existing accounts.
Process
1. Create treaty
Create a treaty with a period with the start date January 1, 2003 and the end date December 31, 2003.
2. Define the periods for forecast and estimation rules
Branch to the “Forecast and Estimation” tab page at treaty level and enter the dates for the corresponding
period in the header dialog. These dates represent a unique period that will later be assigned a set of
estimation parameters.
The period to which a set of estimation parameters rule is assigned depends on the dates entered in this
dialog and the accounting frequency defined in the treaty section header.
For the purposes of this example, set all dates (start date of occurrence period, underwriting period, and
accounting period) to the start date of the treaty period. Leave the fields for the end dates empty.
3. Enter rules
You can now enter the rules themselves. Select the relevant entry and choose to branch to the
subdialog where you maintain the entries. Choose .

Create four rules with the following values.
Rule 1
○ Rank: Select any rank from the input help
○ Usage: Y,F (year-end forecast)
○ Entry code: 1750 (GNPI)
○ Reference period: PER (period)
○ Comparative method: EVERY (every difference)
○ Reference year: none
○ Amount: 15,000,000
○ Currency: Enter the currency for the treaty
Rule 2
○ Rank: Select a rank from the input help with a higher value than that for the rank for the first rule
○ Entry code: 1701 (premium (+))
○ Percentage: 3.5
○ Calculation base: PE01 (forecast and estimation (GNPI))
Rule 3
○ Rank: Select a rank from the input help with a higher value than the rank for the first and second rule
○ Entry code: 3100 (loss payment)
○ Percentage: 85.00
○ Calculation base: PE03 (forecast and estimation (premiums after advance payment))
Rule 4
○ Rank: Select a rank from the input help with a higher value than the rank for the first, second, and third
rule
○ Entry code: 2400 (brokerage)
○ Percentage: 10.0
Meaning of the Individual Field Values
You can see that the usage for all four rules has been defined as a “year-end forecast”. These entries are
pure forecasts, since the actual/estimate indicator assigned to this usage represents a forecast (see the
corresponding documentation for Customizing).
Moreover, the reference period for all four entries is “period”. This means that the subsequent background
job only generates resulting postings if the calculation date of the background job falls within the treaty
period, or if the rule in the treaty has been changed since the last background job. In this example, the
background job is scheduled for the end of 2003, so all four forecast rules are applied.

4. Processing of the forecast and estimation rules
The system processes these four rules as follows.
First it posts the amount entered (15m) to the target entry code 1750 (resulting posting). The calculation
base PE01 defined in the second rule is then applied to this posting. This calculation base only contains the
entry code 1750, which is set at 100% with the plus/minus sign 1.
The value of the calculation base PE01 is multiplied by the defined percentage and saved as a resulting
posting for the entry code 1701 (15m x 3.5% = 525,000).
Next the system generates the loss posting for entry code 3100. To do this, the system applies the
calculation base PE03 to the posting result from the second rule and multiplies it by the percentage
defined in the corresponding calculation rule. The calculation base therefore contains the entry code 1701,
the plus/minus sign 1- and the percentage 100.
This gives you 525,000 x (+1) x (-1) x 0.85 = -446,250 (posting amount x sign of the entry code x sign of the
calculation base x percentage).
The system then multiplies the result by the plus/minus sign for the target entry code 3100 and posts the
resulting value (-446,250 x (-1) = 446,250).
In the fourth and last rule, the calculation base PE03 is applied to the resulting posting from the second
rule to calculate the resulting posting for entry code 2400. This is done as follows: The calculation base
PE03 is applied to the amount 525,000. In other words, the amount posted to entry code 1701 is multiplied
by the plus/minus sign for the entry code (+1) and the plus/minus sign in the calculation base definition
(-1). This gives you 525,000 x (+1) x (-1) = -525,000. The resulting value is then multiplied by the
percentage rate and the plus/minus sign of the target entry code. The value posted to entry code 2400 is
therefore -525,000 x 10% x (-1) = 52,500.
The system generates these postings when you run the “Forecast and Estimation” background job. Enter
the following parameters:
○ Treaty: your treaty
○ Usage: Y, F
○ Financial year: 2003
○ Month: 12
○ Detailed log: yes
○ Target account status: default = do not split, calculate, release
The calculation date for the background job is December 31, 2003, based on the entries for the accounting
year and accounting period. Since this date falls within the treaty period, and all the forecast rules have the
reference period "period", all four rules are processed.
The generated account is then assigned to the corresponding financial period of the financial year 2003.
Since you have set the “Detailed Log” checkbox, the system returns a success message. The background
job creates an account with the actual/estimate indicator “Forecast” that contains the following postings.
Entry Code Underwriting Year Date Occurrence Year Date Original Amount/Amount
Posted
1750 01/01/03 01/01/03 15,000,000
1701 01/01/03 01/01/03 525,000
3100 01/01/03 01/01/03 446,250

2400 01/01/03 01/01/03 52,500
You can see the following:

The actual/estimate indicator for the account has the category “Forecast”, which was derived from the
usage.
The account has been assigned the accounting year 2003 and the accounting period "year". This is
because the entries in the selection screen for the background job override the setting in the treaty
(accounting frequency: 3-monthly).
Since you did not enter a currency in the forecast rules, the background job processed all the amounts in
the leading currency of the treaty section (EUR).
The postings in the generated account correspond exactly to the above values. If you restart the same
background job at a later point in time, the system does not generate a new account: Applying the
individual forecast rules produces the same results as in the first run. The system compares the calculated
values to the values already posted to the target entry codes. In the second background job, it therefore
recognizes that no additional postings are necessary.
5.4.9.3 Comparative Methods
This example demonstrates the effect of the various comparative methods within forecast and estimation
rules.
1. Create treaty with forecast and estimation rules

Create a treaty with the following rules. This procedure is described in Creating Dependent Forecasts Using
Amounts and Calculation Bases [page 435].
The following applies to all rules in this example:
○ Leave empty any fields not mentioned
Rule 1
○ Usage: Y, F (year-end forecast)
○ Amount: 100,000,000
Rule 2
○ Entry code: 1711 (estimated premium)
○ Comparative method: MAX (retained line)
○ Percentage: 20
○ Calculation base: PE01 (forecast and estimation (GNPI))
○ Deduction base: PE02 (forecast and estimation (premium))
Rule 3
○ Rank: Select a rank from the input help with a higher value than that for the rank for the preceding rule
○ Usage: Y, E1 (year-end estimate – payable)

○ Entry code: TE01 (technical profit)
○ Comparative method: POS (positive difference)
○ Percentage: 100
○ Calculation base: PE05 (forecast and estimation (estimated premium))
○ Deduction base: PE06 (forecast and estimation (loss payment after advance payment))
Rule 4
○ Entry code: 2700 (profit commission)
○ Percentage: 20
○ Calculation base: PE08 (forecast and estimation (profit commission))
Rule 5
Usage: Y, E1 (year-end estimate – payable)
Entry code: TV01 (technical loss)
Comparative method: MAX (retained line)
Percentage: 100
Calculation base: PE09 (forecast and estimation (technical result))
Rule 6
○ Entry code: 2103 (loss participation)
○ Percentage: 25
○ Calculation base: PE10 (forecast and estimation (loss participation))
2. Create account
Next, manually create an account for the treaty section (Actual/Estimate Indicator: FINAL) with the
accounting year “2003”, the accounting period “YEAR”, and the following postings.
Posting 1
○ All date entries: January 1, 2003
○ Amount in original currency/amount posted: 3,800,000
Posting 2
○ All date entries: January 1, 2003
○ Amount in original currency/amount posted: 3,800,000
Set the status of the account to “For Batch Release”.
3. Run the background job for the first time
Run the background job for the first time to apply the forecast and estimation rules for this treaty. Enter the
following parameters:

○ Month: 12
This first background job generates an account with the following postings.
Posting 1
○ Underwriting year and occurrence year start date: January 1, 2003
○ Original amount: 100,000,000
Posting 2
You can see that only the rules with the usage “Year-End Forecast” have been processed. The account has
also been assigned the actual/estimate indicator for a forecast.
The accounting period for the generated account is based on the entries in the selection screen for the
background job, rather than the accounting frequency entered in the treaty (3-monthly).
Since only two rules in the treaty were forecast rules, only two resulting postings are generated. The first
posting amounts to 100m, and the second is calculated as follows.
The system first applies the calculation base for the second rule: 3.5% x 100m = 3.5m. The calculation
base PE01 is defined as 100% of entry code 1750.
The value of the deduction basis is 3.8m, based on the premium of 3.8m that was posted manually. The
settings for the deduction basis PE02 are 100% of entry code 1701.
With the comparative method “MAX”, the resulting posting is 3.8m (retained line of 3.5m and 3.8m).
4. Run the background job for the second time
Now run the background job again, but this time for the estimations. Enter the following parameters:
○ Month: 12
This second background job generates an account with the following postings.
Posting 1
○ Entry code: TE01 (technical profit); underwriting year and occurrence year start date: January 1, 2003;
original amount: 2,100,000
Posting 2
○ Original amount: 420,000
The system calculates these results as follows.
It first applies the calculation base PE05 (100% of entry code 1711) and multiplies it by 100%.
This gives you 100% x 3.8m = 3.8m. The deduction base is defined as 100% of entry code 3100 with
reversed plus/minus sign.
Applying this calculation base produces (-1) x 1.7m x (-1) = 1.7m. The first minus sign originates from the
calculation base definition, and the second from the definition of the loss entry code 3100.

These two values are now offset against each other using the comparative method “POS”. The result of this
calculation is 3.8m – 1.7m = 2.1m. Since the target entry code TE01 does not yet contain any postings, this
amount is posted.
The system still has to process the 20% profit commission. The corresponding calculation base is defined
as 100% of entry code TE01 with reversed plus/minus sign.
The resulting posting is calculated as follows:
2.1m x 20% x (-1) x (-1) = 420,000
Again, the first minus sign originates from the calculation base definition, and the second from the target
entry code, in this case 2700.
The system then processes the subsequent prognosis and estimation rules for the loss and loss
participation. However, since no losses have occurred, no resulting postings are created.
To see the effect of the loss participation calculation, change the underlying posting data by creating an
account with the following posting:
This results in a loss of 100,000.
To calculate this loss and the corresponding loss participation, run the background job again with the same
parameters as for the second job.
The other attributes for the account correspond to those for the first manual account. Again, set the status
of this account to “For Batch Release”.
5. Run the background job for the third time
This third background job generates an account with the following postings.
Posting 1
○ Entry code: TE01 (technical profit)
○ Original amount: - 2,100,000
Posting 2
○ Original amount: - 420,000
Posting 3
○ Entry code: TV01 (technical loss)
Posting 4
○ Entry code: 2103 (loss participation)
Since a loss has occurred, this must first be offset against the two profit-based postings resulting from the
second job.
The loss posting is then generated by applying the calculation base PE09. The calculation base PE09 is
defined as 100% of entry code 1711 and 100% of entry code 3100. The loss posting is calculated as follows:
max[(-1)x{(+1)x3.8m +(+1)x (–1)x 1.7m +(+1)x (-1)x 2.2m}, 0] = 100,000
The posting amounts for the entry codes 1711 and 3100 are multiplied by the respective plus/minus signs
for the entry code and calculation base. The two results are added together and then multiplied by the
plus/minus sign of the target entry code. The system then applies the comparative method and posts the
resulting value to the target entry code.

Once the loss has been calculated, the system can derive the loss participation using the calculation base
PE10 (100% of TV01 with reversed plus/minus sign).
5.4.9.4 Effect of Filter Function on Calculation Bases
Use
This example demonstrates how the actual/estimate indicator and the derived combinations of actual/
estimate indicators act as filters when the calculation bases in a forecast and estimation rule are applied.
Process
1. Enter rules
Assume that you have the same treaty as in the example Creating Dependent Forecasts Using Amounts
and Calculation Bases [page 435], but with the following two forecast and estimation rules.
Rule 1
○ Entry code: 2101 (provisional commission)
○ Amount: 15,000,000
○ Filter for calculation base: FOREC (estimate indicator used for forecast)
Rule 2
○ Entry code: 2100 (commission)
○ Percentage: 3.5 Calculation base: PE01 (forecast and estimation (GNPI))
○ Filter for calculation base: EST1 (estimate indicator for estimate – affordable)
The two rules are almost the same. Only the target entry code, usage, and calculation base filter differ.
If you look at the values for the two filters in the Customizing activity “Edit Combination of Actual and
Estimate”, you will see that the combination of actual/estimate 2 refers to estimate 2, and that combination
of actual/estimate 3 to estimate 1, 3 and 4.
2. Create accounts
Create two accounts manually, which contain the following actual/estimate indicators and postings.
Account 1
○ Actual/estimate indicator: FOREC (forecast)
○ Posting: EUR 1000 to entry code 1701 on January 1, 2003
○ Accounting period: YEAR; set the status of the account to “For Batch Release”.

Account 2
As the first account, but with the following entries:
○ Actual/estimate indicator: FINAL (final account)
○ Posting: EUR 800 to entry code 1701 on January 1, 2003
3. Run the background job
You then run the background job twice (once for the forecast rules and once for the estimation rules) with
the following parameters.
Parameters for First Background Job
○ Month: 12
○ Target status of the account: default = do not split, calculate, release
Parameters for Second Background Job
○ Usage: Y, E1 (the other entries are the same as for the first background job)
These background jobs generate two different accounts.
Account Generated by First Background Job
○ Actual/estimate indicator: FOREC (forecast)
○ Posting: EUR 200 to entry code 2101 (provisional commission)
Account Generated by Second Background Job
○ Actual/estimate indicator: EST1 (estimate, payable) Posting: EUR 160 to entry code 2100
(commission)
The first account has been assigned the actual/estimate indicator for a forecast. It has one posting, which
was calculated solely on the basis of the posting in the first manual account.
The second account is an estimated account. The resulting posting was calculated solely on the basis of
the posting in the second manual account.
5.4.9.5 Division of Calculation Bases to Generate

Percentages
Use
This example demonstrates how the percentage value in a forecast and estimation rule can be generated
automatically by dividing two calculation bases.
Process
1. 1. Create a treaty with rules

Assume that you have the same treaty as in the example "Effect of Filter Function on Calculation Bases",
but with the following forecast and estimation rule:

○ Entry code: 2301 (handling costs)
○ Calculation base numerator: PE13 (forecast and estimation (calculation base numerator))
○ Calculation base denominator: PE12 (forecast and estimation (calculation base denominator))
○ Calculation base: PE14 (forecast and estimation (calculation base for divisor))
The calculation bases for the forecast and estimation rule (numerator and denominator calculation bases)
contain the following entry codes:
○ PE14: 20% of 1701 and 20% of 1730
○ PE13: 100% of 3100
○ PE12: 100% of 1701
If you look at the entries for the respective calculation bases in conjunction with the forecast and
estimation rules in the treaty, you can see the intended effect: The numerator calculation base is divided by
the denominator calculation base to produce a loss ratio, which is based on all the premiums before
reimbursement. 20% of this loss ratio is offset as costs, giving you the total premium after reimbursement.
2. Now create two final accounts manually, with the following postings.
Account 1
○ EUR 1000 to entry code 1701 (all dates: January 1, 2003)
Account 2
Both accounts have the accounting year “2003” and the accounting period “YEAR”.
Set the status of both accounts to “For Batch Release”.
3. Calculation by background job
Run the “Forecast and Estimation” background job with the following parameters:
○ Month: 12
○ Status of target account: default = do not split, calculate, release
This produces a result posting of EUR 96 to entry code 2301.
How is this posting calculated?
(costs of 20% x (1000 – 200) x (600/1000) = 96).
What happens if the value for the denominator calculation base turns out to be 0?
The system logs the error and displays a corresponding message at the end of the job. The forecast and
estimation rule itself is excluded during further processing. However, existing accounts for the target entry
code defined in the rule are not changed.

5.4.9.6 Using Development Patterns for Forecasts and
Estimations
This example demonstrates how development patterns can be used to map a series of projected posting values
over time, and then convert them into real postings.
In a treaty based on the occurrence year, for example, development patterns can be used to map the premium
income and loss payments.
1. Enter rules
Assume that you have the same treaty as in the example Division of Calculation Bases to Generate
Percentages [page 443], but with a different period (January 1, 2000 to December 31, 2000 instead of
January 1, 2003 to December 31, 2003).
Enter the following forecast and estimation rules for the period from January 1, 2000 to December 31,
2000.
The following applies to all rules:
○ Reference period: ACCTY (accounting year)
Rule 1
○ Amount: 10,000
○ Calculation base: PE15
Rule 2
○ Development pattern: ESTP (estimated premiums)
○ Calculation base: PE16
Rule 3
○ Development pattern: FOREC (test for forecast)
All three rule entries have the same usage, making the actual/estimate indicator in the generated account
a forecast.
The last two rules contain development patterns for calculating the estimated values. You create these
development patterns in Customizing.
If you first run the background job for forecasts and estimates with the first half-year 2000 as the
accounting period, the system generates the following postings:
○ EUR 10,000 for entry code 1711 (estimated premium)
○ EUR 5,000 for entry code 1701 (premium)
○ EUR 1,000 for entry code 3100 (loss)
(All dates: January 1, 2000)
The system first posts the amount for the estimated premium, and then applies the calculation bases PE15
and PE16 in the other two rules to this amount, each at 100%.
These values are then multiplied by the percentage value in the development pattern. Processing for both
development patterns begins with the start date for the accounting period (based on the reference period
“Accounting Year”).

The date that is used to read the respective percentage value from the development pattern is the last day
in the posting interval specified on the selection screen for the background job.
In this case, the system reads 50% for the premium and 10% for the loss.
The resulting postings amount to 5,000 for premiums and 1,000 for losses.
You now run the background job again, but this time for the second half-year 2000.
The date that is used to read the respective postings is now December 31, 2000, so the system reads
100% for premiums and 10% for losses.
The postings for the target entry codes amount to 10,000 and 1,000. These postings are then offset with
the existing postings so that EUR 5,000 is posted to entry code 1701 (premium).
If you run the background job again for accounting year 2002, this results in a posting of EUR 2,000 to
entry code 3100 (loss).
Since the premiums have not changed, only the development pattern for the loss is relevant. The system
reads the value 30% for the calculation date December 31, 2002, which works out at 3,000. This is offset
against the existing amount of 1,000 in the target entry code, resulting in a posting of 2,000.
5.4.9.7 Cumulative Versus Distributive Logic in

Development Patterns
Use
If you use development patterns in a forecast and estimation rule (see the example in Using Development
Patterns for Forecasts and Estimations [page 445]), you can define the processing logic for the development
pattern in the Customizing activity Edit Development Patterns. The logic can be either “cumulative” or
“distributive”.
Cumulative logic is the logic that was used in this example.
If you opt for distributive logic, the system also reads the percentage rate from the development pattern and
calculates the corresponding amount with the value from the calculation base, as for cumulative processing.
However, in distributive mode this amount is offset against only certain accounts when the resulting posting is
calculated. Accounts are included only if the accounting period falls within the affected development pattern
interval.
Process
1. Create forecast and estimation rule

Assume that you have the same treaty as in the example Using Development Patterns for Forecasts and
Estimations [page 445], but with the following forecast and estimation rule:
○ Entry code: 1701 (premiums (+))
○ Development pattern: BSP9 (test)

The calculation base defined in the rule corresponds to 100% of entry code 1711 (estimated premium).
The development pattern BSP9 is set to “cumulative” in Customizing (“Distributed Postings” checkbox is
not set). It contains the following values.
1 1 5
2 2 15
3 3 18
4 4 5.555
5 5 6.666
6 6 7.777
7 7 45
8 8 58
9 9 80
10 10 100
2. Account for cumulative estimation

Create the following account and posting (Distributed Posting checkbox is not set in the development
pattern):
○ Financial period: 3 / 2003
○ Posting: EUR 1,000 for entry code 1711 (estimated premium)
Set the status of both account to “For Batch Release”.
Run the “Forecast and Estimation” background job for your treaty with the following parameters:
○ Month: 3
This results in a posting of EUR 50 to entry code 1701 (premium (+)).
Run the background job again for accounting year 2001:
○ Usage: Y, E1
○ Month: 3. This results in a posting of EUR 100 to entry code 1701 (premium (+)).
3. Account for distributive estimation

If you delete the two generated accounts, and then set the development pattern to "distributive" in
Customizing, running the same two background jobs generates the following resulting postings.
First background job:
○ EUR 50 to entry code 1701
Second background job:
○ EUR 150 to entry code 1701
The system reads 15% from the development pattern for the premium estimation rule, which is then
multiplied by the calculation base value 1,000. However, because we have opted for distributive logic, the
resulting value 150 is only offset against posting data that falls within the accounting period for this
development pattern percentage, in this case the accounting year 2001.
Since the first resulting posting of 50 was posted in the accounting year 2000, using distributive logic leads
to creation of a second account with a posting of 150 (instead of 100 for cumulative processing).
5.4.9.8 Group Processing and Multiple Inheritance
Use
You can define forecast and estimation rules at group level, and then distribute them to the assigned treaty
sections.
This may lead to a situation where a treaty section is assigned more than one forecast and estimation rule with
the same target entry code. Rules may be assigned via a group, or entered directly in the individual treaty
section. These multiple inheritance problems are dealt with by the override logic during forecast and
estimation processing. If a forecast and estimation rule defined in the treaty section itself has the same target
entry code as a rule assigned via a group, the group rule is ignored.
These features are demonstrated in the following examples.
Process
1. Create group with forecast and estimation rule

You begin by creating a group with a group category that is relevant for estimates. You can see whether a
group category is relevant for estimates in the Customizing activity Edit Group Category (you must set the
“Estimate” checkbox).
Assign a treaty to the group period January 1, 2000 to December 31, 2002. This example uses the same
treaty as in the example "Cumulative Versus Distributive Logic in Development Patterns" and also the same
forecast and estimation rule.
You then define a prognosis and estimation rule for the group with the following data:
○ Start of period: January 1, 2000 (in all cases)
○ Reference period: FINYR (financial year)

○ Percentage: 7
○ Calculation base: PE16 (forecast and estimation (estimated premium (-)))
The calculation bases specified for the two rules (group rule and rule defined for the treaty) both contain a
single entry code, which is 1711 in both cases, but with different plus/minus signs.
2. Create account
You then create an account with the following posting manually:
○ Dates: January 1, 2000 (in all cases)
○ Original amount/amount posted: EUR 1000
Next, run the background job with the following entries:
○ Month: 3
The background job generates the following resulting postings.
Posting 1
○ Amount: EUR 70
Posting 2
○ Dates: January 1, 2000 (in all cases)
○ Amount: EUR 150
The first posting originates from the rule for the group (7% of 1,000 from the calculation base PE16). The
second posting originates from the rule for the treaty (development pattern value 15% and calculation
base value 1,000).
Now create a second forecast and estimation rule for the group, with the target entry code 1701:
○ Percentage: 10
Run the background job again with the same selection parameters. This time, the second rule defined for
the group is overridden by the rule defined for the treaty. Since the result matches the existing postings, no
additional account needs to be generated.

5.4.9.9 Override Logic: Default - Group - Treaty
The previous example demonstrated how forecast and estimation rules defined for a treaty override those
defined for a group. However, you also can also map forecasts and estimations using the global development
patterns in Customizing.
Assume that you have a treaty with the following forecast and estimation rules.
Rule in treaty 1:
● Rank: 1
● Usage: Y, F (year-end forecast)
● Entry code: 3200 (annuity payment)
● Reference period: ACCTY (accounting year)
● Amount: -
● Percentage: 10
● Reference year: none
● Comparative method: EVERY (every difference)
● Calculation base: PE18 (forecast and estimation (GNPI after advance payment))
Rule in treaty 2:
● Rank: 2
● Entry code: 2100 (commission)
● Amount: EUR 850
● Percentage: -
You then create a group, assign it to the above treaty section, and define the following forecast and estimation
rules.
Rule in group 1:
● Rank: 1
● Dates: January 1, 2000 (in all cases)
● Entry code: 3100 (loss payment)
● Percentage: 12
● Calculation base: PE18
Rule in group 2:
● Rank: 2
● Dates: January 1, 2000 (in all cases)

● Entry code: 3100 (annuity payment)
● Amount: EUR 850
● Percentage: 14; reference year: none
Enter the following three global parameters for forecast and estimation in Customizing for Basic System under
Forecast and Estimation Maintain Global Parameters for Forecast and Estimation .
The following applies to all three rules:
● Usage: 10
● Start date: January 1, 2000
● End date: December 31, 2003
● Treaty category: 1
● Nature of treaty: P
● Mode: occurrence year
● Reference period: 3
● Reference year: 3
Rule 1
● Rank: 11
● Entry code: 1701
● Percentage: 25
● Calculation base: PE01
Rule 2
● Rank: 21
● Percentage: 15
Rule 3
● Rank: 31
● Percentage: 15
The system then applies the following override logic.
Forecast and Estima Entry Code Entry Code Entry Code Entry Code
tion Rule
Default 1701 3100 3200
Group 3100 3200

Forecast and Estima Entry Code Entry Code Entry Code Entry Code
tion Rule
Treaty 3200 2100
Rule used 1701 (default) 3100 (group) 3200 (treaty) 2100 (treaty)
Next, manually create a posting for the financial period 4/2003:
● FI posting date: April 1, 2003

● Accounting year: 2000
● Accounting period: YEAR
● Entry code: 1750 (gross net premium income (GNPI))
● Amount: EUR 1,000,000
Note that the calculation base for forecast and estimation rules contains the entry code 1750 only. Run the
“Forecast and Estimation” background job with the following parameters:
● Usage: Y, P
● Accounting year: 2000
● Accounting period: YEAR
● Financial year: 2003
● Month: 3
The background job generates the following resulting postings for the occurrence and underwriting year 2000.
EUR 250,000 to entry code 1701 (premium (+))
EUR 120,000 to entry code 3100 (loss payment)
EUR 100,000 to entry code 3200 (annuity payment)
EUR 850 to entry code 2100 (commission)
5.4.9.10 Forecast and Estimation in Different Currencies and

Changeover to the Euro
Use
When you enter a forecast and estimation rule, you can enter a currency for the forecast.
If you do not enter a currency, the system uses the leading currency for the relevant section.
If accounts and postings are entered in different currencies, these are translated into the forecast and
estimation currency when the forecast and estimation is calculated. In other words, both the calculation base
evaluation and the resulting posting are performed in the currency of the forecast and estimation rule.
However, this rule is superseded by the “currency changeover”. Following the introduction of the euro, various
currencies need to be converted into euros at a fixed rate as of a certain date.

You make the necessary settings in the currency conversion table. If you calculate a forecast, and the currency
conversion table dictates that the forecast currency needs to be translated into euros, the forecast is made in
euros, as is the resulting posting.
Process
1. Create treaty with rules and currency split

This example uses a treaty with the following forecast and estimation rule:
○ Entry code: 1701 (premium)
○ Currency: DEM
○ Amount: 2,000
You enter DEM and EUR in the currency split for the treaty both with the same account currency; you enter
“M” as the exchange rate type and do not specify a share in percent.
The Customizing settings under Default Values Currency Changeover (to Euro) Currencies for
Changeover specify that the currency DEM belongs to the euro zone and, as such, is converted to the
euro as of January 1, 2002.
Run the Forecast and Estimation background job with the following parameters:
○ Usage: Y, F
○ Financial accounting date: December 31, 2009
The background job generates an account with a resulting posting of EUR 1001.50 to entry code 1701. Even
though the forecast and estimation rule was defined in DEM, the system automatically converts the
resulting posting and displays it in EUR.
5.4.9.11 Restricting Data According to Financial Year and

Previous Year
Use
The reference year restricts the time frame of postings to which the calculation bases in a forecast and
estimation rule are applied: financial year: only postings in the accounting year of the background job; previous
year: only postings from the previous year; if field is empty: all postings for which the end date of the
accounting period is not after the calculation date of the background job.

Process
1. Create forecast and estimation rules

Assume that you have the same treaty as in the example Forecast and Estimation in Different Currencies
and Changeover to the Euro [page 452], but with the following forecast and estimation rules entered for
the currency CHF.
Rule 1
○ Entry code: 2100 (commission)
○ Reference year: PYEAR (data applies to previous year)
○ Percentage: 20
Rule 2
○ Entry code: 3303 (loss expenses)
○ Percentage: 5
○ Calculation base: PE07 (forecast and estimation)
2. Create accounts
Create two accounts with the following data.
Account 1
○ FI posting date: April 3, 2003
○ Posting 1: CHF 100 to entry code 3100 (loss payment)
○ Posting 2: CHF 80 to entry code 1701 (premium (+))
Account 2
○ Posting 1: CHF 25 to entry code 3100 (loss payment)
○ Posting 2: CHF 60 to entry code 1701 (premium (+))
Run the background job with the following parameters:
○ Month: 3

The background job generates the following accounts and postings:
○ Generated account 1: CHF 16 to entry code 2100 (commission)
○ Generated account 2: CHF 6.25 to entry code 3303 (loss expenses)
What do you need to consider when analyzing these results?
First of all, a commission of 16 is posted to the entry code 2100 for the accounting year 2000 (80 x 20%,
since the commission calculation base only applies to posting data for the year before 2001, so only the
data for 2000 is included).
The loss expense posting comes to 6.25 ((100 + 25) x 5%), which is posted in the accounting year 2001, as
defined in the selection screen for the background job.
5.4.9.12 Effect of the Reference Period
Use
The reference period defines when the rule is calculated. There are three possible settings.
If the reference period is set to “Financial Year”, the rule is always calculated when the calculation date of the
background job falls within a technically open financial year. Otherwise, no calculation is performed.
If the reference period is set to “Period”, the rule is calculated when the calculation date for the background job
falls within the treaty period, or when rule in the treaty has been changed since the last background job.
If the reference period is set to “Accounting Year”, the rule is calculated when the accounting period specified in
the selection screen for the background job overlaps with the accounting period for the rule, which is based on
the start and end dates for the accounting period.
Process
1. Enter rules
Assume that you have a treaty with the following forecast and estimation rules.
Rule 1
○ End of accounting period: December 31, 2000
○ Amount: 1000
Rule 2

○ Amount: 1200
Rule 3
○ Entry code: 2111 (estimated commission)
○ Percentage: 20
2. Create manual posting
You now create a manual posting:
○ All other underwriting and occurrence dates: January 1, 2000
○ Amount: 1500
You run the background job for the first time with the following parameters:
○ Usage: Y, E1
○ Month: 3
The background job generates the following account with three postings:
○ All dates in the account: January 1, 2000
○ Financial period: 12/2000
○ CHF 1000 is posted to entry code 3100 (loss payment)
○ CHF 1200 is posted to entry code 1701 (premium (+))
○ CHF 300 is posted to entry code 2111 (estimated commission)
All the rules are processed with these settings.
To influence the calculation base of the rule with the reference “Period”, change the manual posting of CHF
1500 to CHF 1600. If you then repeat the background job, no resulting postings are created. This because
the calculation date of the run (December 31, 2001, end of the specified accounting period) does not fall
within the period and the postings already created for all the other rules are still correct.
However, if you also change the rule with the reference “Period” in the treaty, save it again (resetting the
change before saving), and repeat the background job once more, the system creates a resulting posting of
CHF 20 to entry code 2111 for the rule with the reference “Period”.
5.4.9.13 Reversal in the Following Financial Year
When an estimate is entered – either manually, or automatically when the background job processes a forecast
and estimation rule in the treaty – you need to make sure that the estimation will be reversed when certain
events take place.

The FS-RI system supports two reversal methods: automatic reversal in the following financial year, or reversal
following receipt of the corresponding final account.
The first method is triggered when you release the estimated account. This is illustrated in the following
example.
An estimated account with CHF 1000 in entry code 3100 (loss payment) is posted manually for a treaty. In
internal Customizing, you must set the estimate account reversal method to “Automatic Reversal in the
Following Year” (method 1).
When you release the account, the system automatically creates a reversed estimate. This is an account with
an offsetting posting for the same amount.
5.4.9.14 Reversal After Receipt of Final Account
When an estimate is entered – either manually, or automatically when the background job processes a forecast
and estimation rule in the treaty – you need to make sure that the estimation will be reversed when certain
events take place.
The FS-RI system supports two reversal methods: automatic reversal in the following financial year, or reversal
following receipt of the corresponding final account.
The second method is triggered when you release the final account. This is illustrated in the following example.
An estimated account for a treaty is posted manually. In internal Customizing, you must set the estimate
account reversal method to “Reversal After Receipt of the Final Account” (method 2).
No other accounts are created when you release the estimated account.
Later on, you create the final account. The accounting period for this account is the same as for the estimated
account. Also, this account has the actual/estimate indicator “FINAL”, indicating that it is a final account. To
reverse the estimated account, this account must be defined as the closing account for the respective
accounting period. This is done by setting the “Statistics” checkbox.
When you release this account, the system creates the estimated account as in the example Reversal in the
Following Financial Year [page 456].
5.4.9.15 Importing Templates
You can define estimate templates in Customizing.
Choose Forecast and Estimation Edit Forecast and Estimation Templates .
Create a header entry in this Customizing activity. Select this entry and double-click Rank to branch to the
details of the templates, where you enter the corresponding forecast and estimation rules.
Rule 1
● Rank: 1
● Usage: 10

● Amount: 1,000
Rule 2
● Rank: 2
● Usage: 10
● Amount: 1,250
These entries are the same as those for a treaty or group.
If you create a treaty and want to import a template, you must specify in the treaty header data the template to
be imported (in the Rule Definition Template for Forecast/Estimation field under Additional Data).
You then enter the header details for a forecast or estimation, and branch to the (empty) main screen.
If you choose the Load Template pushbutton, the system imports the template from the Customizing activity.
Once you have loaded the template, you can save it as normal and process the rules in the background job.
5.4.9.16 Effect of Statuses for the Period, Section, and Share
Use
You can enter statuses for periods and shares; these statuses affect how the forecast and estimation rules are
processed.
If one of these statuses does not allow posting, the corresponding forecast or estimation rule is not processed.
Process
1. Create treaty with participations

Assume that you have a treaty with two sections and two shares, where the following settings have been
made for the participations:
○ All participations are signed line, are valid for the entire treaty period, and relate to the treaty.
Participation 1
○ Share: 2
○ Section: 1
○ Share in %: 50
Participation 2
○ Share: 2
○ Section: 2
○ Share in %: 60
Participation 3

○ Share: 3
○ Section: 1
○ Share in %: 50
Participation 4
○ Share: 3
○ Section: 2
○ Share in %: 40
○ Status: expired
The status of the period allows posting.
2. Enter rules
Enter a forecast and estimation rule for each of the two sections.
Run the “Forecast and Estimation” background job with the following parameters:
○ Usage: Y, F
○ Accounting year: Q1
○ Month: 3
3. Generated accounts
The system generates three accounts:
○ An estimated account for section 1, share 2
No account was created for share 3 in section 2. This is because the status of the share (expired) does not
allow posting.
5.5 Change of Financial Year
Use
This section contains information about the actions commonly used to change the financial year or accounting
period.
Process
We recommend you use the following activities to change the accounting period.
Calculate Advance Premiums
You must any calculate outstanding advance premiums [page 268] before year-end closing.
Final Premiums
In the case of reinstatements [page 270], you must enter any final premiums in the treaties.
Calculate Conditions (Unearned Premiums, Portfolio Entry/Withdrawal)

You have to check for the year being closed whether the result-dependent conditions [page 215] and result-
independent conditions [page 231] in the treaties or global conditions [page 251] have to be calculated. This
can affect unearned premiums and portfolio entries and withdrawals, for example.
Adjust Periods
You use the Adjust Periods [page 535] background job to perform some final calculations, for minimum
amounts in conditions for example, and to release accounts.
Create Estimates
If required, you must create any estimates before the period is closed. You use the forecast and estimation
function [page 413] to do this.
Copy Treaty Periods
You use the Copy Periods [page 534] background job to copy the periods from the old year to those of the new
year, which facilitates the processing of extended business.
Change Accounting and Financial Periods
If you create accounts on an annual basis, when you close a financial year you must close the corresponding
financial period and open a new financial period. You cannot post data to a closed financial period.
If you use the FS-RI solution, you can open and close financial periods on two levels (in SAP FI and in the FS-RI
system). You can release accounts with an FI posting date only if an open financial period exists at both levels
for this date.
The system enables you to block accounts from the FS-RI system before you close the period in SAP FI. This
means you can postprocess data in the FS-CD system if the FS-RI system has already been closed.
For more information about managing financial periods in the FS-RI system, see Management of FS-RI
Financial Periods [page 461].
Carry Forward Reserves
You use the Execute Reserve Carryforward [page 546] background job to create any opening and closing
reserves required for the subsequent year.
Check Temporary Assignments in Customizing
You can enter a time limit for some Customizing activities. If your business environment changes at period-end
closing, we recommend you do this in external Customizing for Basic System. For example:
Interfaces FS-CD Interface Assign Entry Codes to Main Transactions/Subtransactions
Interfaces FS-CD Interface Assign Insurance Types to Classes of Business
Accounting Accounting Principles Edit Derivation Rules
Accounting Accounting Principles Assign Accounting Principles to Company Codes

5.5.1 Management of FS-RI Financial Periods
Use
You use the financial periods defined in the FS-RI system to close FS-RI financial periods independently of the
current account system. This means you can continue to work on these periods in the current account system
after you have closed and locked them in the FS-RI system.
Prerequisites
● You have defined the variant for the company code in the following Customizing activity: SAP
Customizing Implementation Guide Financial Accounting (New) Asset Accounting Valuation Fiscal
Year Fiscal Year Variants Specify Other Versions on Company Code Level
● In Customizing for Basic System under Default Values Edit Defaults for FS-RI , you have used the
Control Closed Financial Periods checkbox to specify whether you want to enter open or closed financial
periods.
Features
You manage the FS-RI financial periods in the FS-RI master data under Financial Periods in FS-RI Edit
Financial Periods . The transaction code is /MSG/RBILPERPF.
Depending on your Customizing settings (see "Prerequisites"), you enter the closed or open financial periods
here.
If you enter closed financial periods, the system interprets as open all periods for which an open financial
period is declared in the FI module and that have not been explicitly declared as closed here.
If you enter open financial periods, the system interprets as open all financial periods for which an open period
has been declared in the FI module and here.
If you do not make any entries, only the specifications from FI are effective.
Defining Whether Posting Is Allowed
You can control whether posting is allowed in a period using the following criteria:
● Company code variant

● Treaty class
● Treaty category
● Combination of actual/estimate
Determination of the Accounting Period If There Are Several Open Periods
If you select the “Control Closed Financial Periods” checkbox (see "Prerequisites") and the closed FS-RI
financial period results in the creation of two open financial periods, the system uses the oldest open FS-RI
financial accounting date.

 Example
FI period of open period: January 2000 to December 2010
RI period of closed period: January 2003 to December 2006
The following open financial periods exist: January 2000 to December 2002 and January 2007 to
December 2010
Earliest possible open RI financial accounting dates: January 2000 or January 2007
Oldest open financial accounting date in this example: January 2000
5.5.1.1 Example: Determination of the Applicable FS-RI

Financial Period
Use
This section provides an example for determining applicable FS-RI financial periods.
Prerequisites
● The company code of the accounts is assigned to variant V001.

● The combination of actual and estimate 1 has an active actual/estimate indicator.
● Account 1 has treaty class 1, treaty category 2, actual/estimate indicator 1.
● Account 2 has treaty class 3, treaty category 2, actual/estimate indicator 1.
Activities
1. The system selects all the FS-RI periods that match the company code or its variant.
Variant Treaty Class Treaty Cate Combina From Year To Year

gory tion of Ac
tual/Esti
mate
V001 1 1 2007 9 2007
V001 3 1 2000 12 2010
V001 1 2000 12 2010

Variant Treaty Class Treaty Cate Combina From Year To Year
gory tion of Ac
tual/Esti
mate
V001 2 1 2000 12 2010
2. The system sets an actual/estimate indicator for each combination of actual and estimate.
Variant Treaty Class Treaty Cate Actual/Esti From Year To Year

gory mate Indica
tor
V001 1 1 2007 9 2007
V001 3 1 2000 12 2010
V001 1 2000 12 2010
V001 2 1 2000 12 2010
3. The system rejects the entries that have a treaty class, treaty category, or combination of actual/estimate
that do not match the current account. It keeps the entries containing placeholders.
Account 1

gory mate Indica
tor
V001 1 1 2007 9 2007
V001 1 2000 12 2010
V001 2 1 2000 12 2010
Account 2

gory mate Indica
tor
V001 1 1 2007 9 2007
V001 2 1 2000 12 2010
V001 1 1 2007 9 2007
V001 1 2000 12 2010
4. The system sorts the remaining entries in descending order according to treaty class, treaty category, and
actual/estimate indicator. After sorting, the placeholders can be found under the specified fields.

Account 1

gory mate Indica
tor
V001 2 1 2000 12 2010
V001 1 1 2007 9 2007
V001 1 2000 12 2010
Account 2

gory mate Indica
tor
V001 3 1 2000 12 2010
V001 2 1 2000 12 2010
V001 1 1 2007 9 2007
V001 1 2000 12 2010
5. The system selects the top entry after sorting.
Account 1

gory mate Indica
tor
V001 2 1 2000 12 2010
V001 1 1 2007 9 2007
V001 1 2000 12 2010
Account 2

gory mate Indica
tor
V001 3 1 2000 12 2010
V001 2 1 2000 12 2010
V001 1 1 2007 9 2007

gory mate Indica
tor
V001 1 2000 12 2010
It then compares the financial periods for the account with the details of the entry that was found, taking into
consideration the Control Closed Financial Periods checkbox.
5.6 Office Integration
You use Office Integration to integrate various OLE2-enabled desktop office applications into the ERP system.
Desktop Office Integration provides an ABAP OO interface, which enables you to start, close, and handle
special office applications through the OLE2 interface. You can open the office application in a separate
window, or in the ERP window.
You can store the documents as required.
5.6.1 Execution and Application
Microsoft Excel is currently the only application available in the FS-RI system.
You call Microsoft Excel in a treaty, loss, or account under Extras -> Microsoft Excel Processing.
A display frame appears that contains the connection to Microsoft Excel. You can then decide whether to
continue or not.
When you choose Microsoft Excel Processing, the system reads the current data from the tab pages, calls
Microsoft Excel, and imports the data using a macro.
The different tables in Microsoft Excel are named after the tab pages on the screen.
If you change the data on the screen, choose Microsoft Excel Processing again. The system closes the active
Microsoft Excel window and opens a new window containing the new data.
You can supply the treaty data transferred to Microsoft Excel to other Microsoft Office applications. For
example, you can use this data to generate standard letters.
5.6.2 Consistency of Data Displayed and Customer Settings
Unfortunately, the data displayed in Microsoft Excel is not always consistent. As you can see when treaty data
is transferred to Microsoft Excel, the date is shown in different formats.

You can avoid this inconsistency only by formatting the fields in the date columns as date fields. This
formatting must be performed in Business Document Service (BDS), but can be performed by the end
customer only. This is because only the end customer knows which fields or columns are displayed and hidden.
After you have transferred data to Microsoft Excel, if columns appear to be missing or if more columns are
displayed than on the screen, either new columns were added during the development process or columns
were hidden by the end customer.
The only way to solve this problem is to change the program code. To do so, go to the form include for the
relevant screen and search for the refresh_dataINCLUDENUMBER form. Here, you can quickly find the part
responsible for the relevant tabstrip control and change it as required.
Let us take as an example the code for exporting the table control for periods in the /MSG/
R_V_KORVASSAPF1001 form include. By scrolling down a little, you can see the code that is used to fill the
columns.
If there are too many columns, simply turn the relevant row into a comment. If any columns are missing, and
these have not been turned into a comment, the user must simply add them at the appropriate position.

6 Current Account
Use
The industry-specific component FS-RI is an integral part of standard SAP software and can be combined with
the FS-CD modules to process general tasks relating to the current account. You can find more information
about SAP transactions in the SAP ERP documentation for insurance.
Alternatively, you can determine the balance carried forward for the final statement. In this case, the system
saves the end balance of the last final statement run persistently. This is used as the balance carried forward
for the next statement run.
6.1 Document Creation
Reinsurance Account Statement and Current Account Statement
You can use the Billing/Account Statement [page 467] function to print RI account data, current account data,
reserves data, and fund data. Before you print you can display a preview of the data on the screen. You can use
selection parameters to restrict the volume of data printed.
Bordereau Creation
You can use the Bordereau Creation [page 475] function to enter a predefined amount of account data into a
bordereau.
The “Repeat Printout” and “Reset” functions are available for final bordereaux.
6.1.1 Reinsurance Account Statement and Current Account

Statement
Use
You use this function to print RI account data, current account data, reserves data, and fund data. Before you
print you can display a preview of the data on the screen.
You can use selection parameters to restrict the volume of data printed.

Current Account PUBLIC 467
Prerequisites
You have configured the following activities in Customizing for Basic System:
● Billing/Account Statement Edit Settings for Billing/Account Statement

This activity contains general settings, such as how data is sorted, or the data in the statement header.
● Billing/Account Statement Edit Texts for Payment Document Types (FS-CD)
This activity defines the standard texts for printing from the FS-CD current account system.
● Interfaces FS-CD Interface Maintain Main/Subtransactions for Current Account Statement
This activity controls the calculation of due dates after the final print run.
● If you use FS-CD as the current account system, see SAP Note 926676 in relation to customer includes.
Features
The current account statement is a record of liquid funds and provides information about open and cleared
items.
The RI account statement is a record of reinsurance-related data and contains the premiums, losses,
commissions, and so on, from the individual accounts printed.
You can also print a summary for each treaty. In this case, all the postings for an account item are totaled.
The statement of reserves contains the FS-RI reserve balance. This is the total of the postings with entry codes
that have been defined as reserves. The reserves are transferred to the RI account statement as additional
information.
You can select whether you want the system to print statistical or balance sheet reserves only (depending on
the respective accounting principles), or both.
The statement of funds held documents the funds created in the FS-RI system. The statement is based on fund
movements classified as fund postings.
The account lists contain the printed accounts. You can display or print the account lists to reconcile balances.
Print Operation
The system prints the reinsurance and current account statements in a single activity. However, you can select
the data to be printed and opt to print only reinsurance accounts, or reinsurance accounts and current
accounts. On the initial screen you can also enter the contact details and the date to appear in the document.
The system prints the data for the current account and RI accounts in one document for each account
recipient and address, based on the specified selections.
The time period on the selection screen restricts the settlement period for the current account data, and the
accounting period for the RI account data. Normally, you only enter the "To" date. This year also defines the
accounting year for the statistical reserves. Leaving the "From" date blank ensures that all the old items that
have already been printed are included in the balance carried forward. It also ensures that payments without a
specified settlement period are included.

468 PUBLIC Current Account
If you enter the financial year, this restricts the accounting year for the current account data and the financial
year in the RI account data and balance sheet reserves. The system prints the selected data in the following
sequence for each document:
1. Current account
○ For each company
○ For each currency
2. Account data
○ For each currency
○ For each treaty
○ For each company
1. RI account 1
2. RI account n
3. RI accounts (summary for treaty)
4. Control list of printed accounts
3. RI reserves for treaty 1 to n
4. RI funds for treaty 1 to n
You can change the sort sequence to meet customer-specific needs by implementing method
CHANGE_ABR_RES_DPO for Business Add-In /MSG/R_A_ABR_BADI.
Provisional, Final, and Repeat Print Run
You use the provisional print run to check the data. You can create a provisional statement as many times as
you want based on pending and released accounts.
The system processes only released accounts in the final print run. The final print run also assigns a document
number and flags the accounts and postings contained in the final statement. After the final print run, the
system totals the printed current account items as the balance carried forward for the next provisional/final
print run.
During the final print run, the system also adjusts the due dates of the open items based on the statement
date.
You can also perform a repeat print run for documents that have already been printed in a final print run. The
function for repeating a print run has a separate selection screen, which you call by choosing the “Repeat
Printout” pushbutton. Here you see the documents that have been generated by a final print run.
You can then select and reprint a document.
You can also delete documents that no longer need to be available for repeat printouts.
Company Codes
You can execute the print run for each company code. In the FS-CD current account system, you can also
perform the run for each company code group. If you do not enter a company code or company code group,
the system prints all the postings found for the specified treaty, treaty category, or print group for all company
codes.
Print Group
You can execute the print run for each treaty or print group. This is controlled using the Customizing setting for
account statements, which is defined for each company code. If you execute the print run for each print group,
the system groups only treaties belonging to the same print group in each document. Treaties that are not
assigned to a print group are not printed.

Currency
The system checks if values have been entered in the selection screen fields for the target currency, valuation
date, and exchange rate type. If this is the case, it translates the amounts in the current account statement and
in the control list for the RI accounts into the corresponding currency.
RI Account Statement
When the system prints the RI account statement, it prints all the accounts that correspond to your selection
parameters. You normally print all the accounts for a business partner in one run so that you can send them to
the partner together. The statement is sent to the account recipient specified in the treaty (to the partner
address selected in the treaty).
Document ID
Every account printed is given a document ID consisting of the date and a sequential number from the number
range interval defined in Customizing.
Data in the RI Account Statement
For an overview of how data is displayed and sorted in the RI account statement, see the corresponding
section.
Current Account Statement
The system selects and stores temporarily the current account data for the current account system. The
system formats the print data independently of the current account system. The system creates a document
for each account recipient and address.
No current account statements are printed for assumed treaties.
Due Date for Printed Invoices
When you execute the final print run, the amounts displayed become due for payment. The system
recalculates the due dates for the open items printed in the final statement to incorporate the time limits in the
treaties and shares, and writes these to the FI documents. You can suppress this function for the current
account system FS-CD by defining the main transactions and subtransactions for the postings you do not want
to be adjusted in Customizing.
Data in the Current Account Statement
For an overview of how data is displayed and sorted in the current account statement, see the corresponding
section.
Statement of Funds Held
If the treaty currency has changed, or the last record has been processed, the system prints any available
funds data, provided you have selected the “Print Funds” checkbox in the selection criteria and fund postings
exist.
Statement of Reserves
The system prints closing reserves only. It prints the reserve balances up to the financial year specified in the
selection criteria, allowing for the fact that postings have already been created for this year or were made for at
least one reserve carryforward.

Activities
1. Choose Billing/Account Statement.

2. Select the data you want to print.
3. Enter the printer data and the other details for the printout.
4. The system selects and transfers the data to the spool program according to the printer data entered. The
system displays a message with the corresponding document number to confirm that the data has been
printed.
 Recommendation
If you want to print larger quantities of data, we recommend that you schedule the billing/account
statement in the background (for example, overnight).
6.1.1.1 Data in the RI Account Statement
The system displays the following data in the RI account statement:
● Accounts with a given status for a company (and a treaty/treaty group) whose posting date is before the
end of the period being processed
● Accounts to printed and liquid postings that have not yet been printed for the accounts found (whose
account items are to be displayed as individual line items or as totals)
Calculation of Totals
During the print run the system totals the individual account line items according to accounting class of
business/main class of business or treaty section, depending on the Customizing settings for billing/account
statements.
The system totals the data according to the following criteria:
● Treaty
● Business partner
● Currency
Sorting Data
The system sorts the data according to the following criteria:
● Currency
● Treaty (the system can also print a cover page for each treaty)
● Company

● Accounting class of business/main class of business, or treaty section
● Blocks for premiums, costs, losses, other expenses, and revenues (if defined in Customizing)
● Account line item
● Occurrence year
6.1.1.2 Data in the Current Account Statement
The system displays the following data in the current account statement:
● Balance carried forward from previous current account statement (if available)
● Current account data from accounts from FS-RI accounting documents
● Current account data from payments made and received
● Balance from all the above transactions
● Cash loss (displayed as separate line, for information purposes)
Balance Carried Forward
The balance carried forward is the balance of all the postings that have already been included in a final print
run.
Current Account Data from Payments Made and Received
This section lists all the individual posting items that have not yet been printed, and for which one of the
following apply:
● The posting clears an open item that is also to be printed.

● The posting is a current account posting that matches the selection criteria. In other words, it has been
assigned to the specified business partner, treaty, and account recipient/address.
● The posting is a currency transfer posting resulting from a payment agreement.
● The posting is a transfer posting entered using the transaction for transfer postings.
Current Account Data from FS-RI Account Documents
This section contains the balance of all postings for the accounting period and treaty that were posted in the
current account system by the account release function in the FS-RI system and have not yet been printed.

Cash Loss
This section discloses a cash loss for information purposes, assuming it has not been cleared by a technical
posting.
Control Break Condition for Current Account Statement
The system starts a new printed page if one of the following is changed:
● Recipient
● Currency
The system totals the current account data for payments made or received according to the following:
● Document type
● Document number
Sorting Data
The system sorts the current account data from RI accounts by:
● Treaty
● FS-RI accounting period
6.1.1.3 Data in the Statement of Funds Held
The system totals the funds held, released, and retained according to the treaty, company, currency, treaty
section, fund type, and underwriting year/accounting year for each recipient (for all addresses). The funds data
is calculated for the current financial year only.
Control Break Condition for Statement of Funds Held
The system starts a new printed page if one of the following is changed:

● Currency
● Recipient
● Treaty number
● Fund type
Grouping
Depending on the Customizing setting, the system groups the data for funds held according to the accounting
class of business/main class of business or the treaty section.
6.1.1.4 Data in the Statement of Reserves
The system displays the current balance of the closing reserves for the respective account recipient (for all
addresses).
After a change in the financial year, you must carry the reserves forward before you can print the statement of
reserves for the following year.
Control Break Condition for Statement of Reserves
The system always starts a new printed page if one of the following is changed:
● Currency
● Treaty number
● Reserve type
The system totals the reserves data according to:
● Account line item
● Accounting class of business/main class of business, or treaty section
Grouping
Depending on the Customizing setting, the system groups the data for reserves according to the accounting
class of business, main class of business, or the treaty section.

6.1.2 Bordereau Creation
Use
You can enter a predefined amount of account data in a bordereau.
The Repeat Printout and Reset functions are available for final bordereaux.
Bordereaux are created by filling the work tables.
The creation of the printed statement or electronic message is not part of the features.
You find the Trigger Bordereau Creation function in the SAP Easy Access menu under Reinsurance Periodic
Processing Document Creation .
Prerequisites
You can define the type of accounting procedure for partners involved that are flagged as the cedent or
reinsurer. You use this accounting procedure to specify whether a partner involved in the role of “Reinsurer” or
“Cedent” receives their accounts or bordereaux in printed form.
 Note
You cannot select an entry here for other partners involved.
You can print bordereaux in addition to the account. By default the system prints RI account statement only.
 Note
The billing/account statement is not affected by the accounting procedure.
If you want to create a bordereau for a partner involved then you must enter this bordereau in the treaty. The
Accounting Procedure field is provided for this purpose on the “Partner Involved Data” tab page under
“Participation Information”.
You can create bordereaux:
● For ceded business only

● Only if the treaty is intended for use in Risk Manager
Features
Trigger Bordereau Creation
The system uses the selection criteria and control data entered by you to find the required data.
Reprint Bordereau or Reset Bordereau Creation

You can select from a list of final bordereaux those that you want to reprint or reset.
Activities
To request a bordereau, select the Trigger Bordereau Creation function. If the system finds the data
successfully, it displays a message with the request number, sender, and recipient.
If you want to print a provisional or final bordereau then you must call the print program with the generated
request number to start the print operation. This procedure also applies if you want to reprint a bordereau.
6.1.2.1 Trigger Bordereau Creation
When you call the Trigger Bordereau Creation function (transaction /MSG/H_BORDANST) the Bordereau –
Selection Program screen appears. Under Selection Criteria and Control Data you can select which accounts
are to be used to create the bordereau.
Selection criteria:
● Company code; the system explicitly asks you for this code if you have not already entered it
● Company code group
● Main class of business
● Treaty number
● Treaty category
● Ceded RM participation
● Reinsurer
● Recipient
● Key date
Control data:
● Request type: provisional, final

● RM accounts: not yet transferred and transferred, transferred
● Include statistical reserves
● Include balance sheet reserves
● Creation date; creation date entered in the bordereau
 Note
You can create a provisional bordereau for Risk Manager accounts that have not yet been transferred to
Basic System or have already been transferred to Basic System. You can create a final bordereau only
for Risk Manager accounts that have already been transferred to Basic System.
The system uses the selection criteria and control data to find the required data. It generates a request number
and saves the data under this request number in a work table. A document number is assigned to the final
bordereau; this number comprises the request number, recipient, and sender. The work table contains values
such as sender, sender address, recipient address, treaty, account currency, risk, policyholder, entry code,
amount, underwriting year, occurrence year, revenue period, and loss number.

The request number of a bordereau must correspond to a number range object, which you must configure in
Customizing.
Amounts are displayed in the work table with a plus or minus sign. The system takes the plus or minus sign
from the “Plus/Minus Sign for Entry Code” column (“+/-Sign EC”) in the Customizing activity Edit Entry Code
Definitions under Basic System Accounting Entry Code .
The work table contains the following liability data:
● Signed line of the ceded participation

The system determines the value from “Our Share, Signed Line” (value type: 66 §UASL) at the start of the
revenue period for the posting.
● Deductible
○ Facultative business: The system determines the deductible for a non-proportional participation at the
start of the revenue period for the posting based on the LUDs of the ceded participation.
○ Obligatory non-proportional business: If the ceded business is also covered by non-proportional
business, the system determines the deductible based on the relevant treaty section and treaty period
of the master treaty. The system then determines the deductible based on the LUDs of the treaty at
the start of the treaty period.
● Liability
○ Facultative business: The system determines the liability for a non-proportional participation at the
start of the revenue period for the posting based on the LUDs of the ceded participation.
○ Obligatory business: If the ceded business is also covered by non-proportional business, the system
determines the liability based on the relevant treaty section and treaty period of the master treaty. The
system then determines the liability at the start of the treaty period based on the LUDs of the treaty.
● Signed line of the involvement of the ceded treaty
The system determines the value from “Share %” in the ceded treaty for the related involvement at the
start of the treaty period based on the posting.
The system currently determines the liability data on the posting date during account creation.
You can use certain values to summarize data when the work table is filled. The system leaves empty the
parameters in the work table selected as summarization criteria. You can use the features of the flexible
summarization of accounts [page 174] to define the summarization criteria.
In the treaty header data you enter the summarization variant to be used by the system.
6.1.2.2 Reprint and Reset a Bordereau
Use
You can enter multiple selection criteria on the Bordereau - Repeat Printout/Reset screen:
● Recipient
● Reinsurer
● Treaty number
● Treaty category
● Responsible for account
● Request number

● Document number
● Key date from/to
The system displays the data found in an ALV Grid:
● Document ID
● Key date from
● Treaty number
● Treaty name
● Reinsurance company number
● Name of reinsurer
● Broker
● Name of broker
● Recipient
● Name of account recipient
● Recipient address (city, postal code, street, and house number)
● CoCd (company code)
● Responsible partner (responsible for account)
● Request number
● Main class of business
● Name of main class of business
● Creation date
● Account sender
● Name of account sender
 Note
The system displays final bordereaux only.
Activities
To reprint a bordereau, select at least one bordereau and choose the Repeat Printout pushbutton.
If you want to reset a bordereau, select the corresponding bordereau and choose the Reset pushbutton. The
data will be available again the next time a bordereau is created. The system then assigns the status Reset in
the work table to the bordereaux that have been reset.
6.1.2.3 Bordereau Creation: Include Reserves
If you want to include the reserves for the bordereau, the system calculates these using the specified key date
according to the year-to-date (YTD) method.
● Balance sheet reserves: selected with the financial year that corresponds to the key date year
● Statistical reserves: selected with the accounting year that corresponds to the key date year
When the system calculates the loss reserve balance it ignores the account and posting number.

When the system calculates the unearned premiums it ignores the account and posting number, and the
revenue period and occurrence date.
The system considers whether the reserves have to be calculated according to a specific accounting principle.
For more information, see the Customizing activity Accounting Principles for Accounting Procedure.
The system does not revalue the reserves.
If you want to revalue the reserves, you must run the Recalculate Conditions (Risk Manager) background job
first.
6.1.2.4 Bordereau Creation: Customizing
Use
Multiple Customizing settings are required to create a bordereau.
Activities
Customizing Activity: Enter Accounting Procedure
You find the Customizing activity Enter Accounting Procedure under FS-RI Reinsurance Basic System
Treaty .
The accounting procedure describes whether a partner involved with the role of reinsurer or cedent receives
their accounts or bordereaux in printed form.
Customizing Activity: Edit Entry Code Definitions
You find the Customizing activity Edit Entry Code Definitions under FS-RI Reinsurance Basic System
Accounting Entry Code .
You have to set the Bordereau Indicator for each entry code that is relevant for the bordereau statement.
Accounting Principles for Accounting Procedure
You find the Customizing activity Accounting Principles for Accounting Procedure under FS-RI Reinsurance
Basic System Accounting Accounting Principles .
If you manage reserves according to different accounting principles, you can specify this here.
For each company code you can specify the accounting principle to be used by the system to calculate the
balance sheet or statistical reserves.

6.2 Integration with FS-CD
The FS-CD system uses the following objects as master data:
● SAP Business Partner

● Insurance objects (abstract objects to which data can be posted)
● Contract accounts (accounts in the FI-CA system to which data can be posted)
This master data is created when you set a treaty period to a status that allows posting; posting data cannot be
created for the treaty until you set a treaty period to a status that allows posting.
6.2.1 SAP Business Partner
With the exception of the owner company, all the partners involved in a treaty (cedents, reinsurers, brokers) are
assigned the role MKK (mass contract invoicing) and can therefore be used in the FI-CA system (and the FS-CD
system). This process runs in the background and is triggered every time you set a treaty period to a status
that allows posting.
6.2.2 Insurance Objects
The FS-RI system uses the following default FS-CD insurance objects:
● Reinsurance treaty objects

The system creates a treaty object when you set a treaty period to a status that allows posting. It
automatically assigns the object with a freely-definable prefix or suffix (IMG) as well as the FS-RI treaty
number.
● Reinsurance fund objects
The system creates a fund object when you release the corresponding account (if you are using an entry
code for funds). It creates a fund object for each business partner and fund type. The fund object is
identified by a prefix or suffix, the partner number, and the fund type.
For more information, see Fund Posting [page 356].
● Broker objects
The system creates a broker object when you set a treaty period to a status that allows posting. This object
records the postings for the brokerage due. The broker object is identified by a prefix or suffix and the
treaty number.
6.2.3 Contract Accounts
In the FI-CA system, contract accounts are subledger accounts that manage the payables and receivables for a
business partner. These accounts are reconciled with the general ledger (FI-GL system). You can assign a
contract account to each insurance object/partner relationship. In the FS-RI system, we recommend that you
manage one contract account for each partner irrespective of the number of insurance objects assigned. To do
this, you must define rules for account creation in the FS-CD system that can be selected in Customizing.

6.2.4 Business Transactions
When you release an account, the system creates payment plan items in the FS-CD system (provided the
account contains FI-relevant entry codes and that the treaty is not statistical). The account number is
transferred to the FS-CD system as the business transaction number. To control account determination, in
Customizing you can assign entry codes to main transactions/subtransactions in the FS-CD system.
6.2.5 Display Account Balances
The following FS-CD account balance roles are delivered with the standard FS-RI system:
● FS-RI – Current Account

This is the standard role for the account balance; it shows the postings for reinsurance treaty objects
belonging to the partner.
● FS-RI – Broker
This role shows all the items that involve the broker.
● FS-RI – Funds
This role shows the items for a reinsurance fund. FS-RI – Loss (treaty independent): This role shows the
items for a loss (you must enter the loss number in the treaty reference field).
The account balance roles are combined with various list types and line layout variants that are defined in
Customizing for the FS-CD system.
6.2.6 Ledger Group
Definition
The ledger group is a combination of ledgers for the purpose of applying the functions and processes of general
ledger accounting to the group as a whole.
Use
The ledger group is important if you use the new multi-GAAP functions of the new FI-GL general ledger in SAP
enhancement package 3 for SAP ERP 6.0.
The FS-RI system finds the corresponding ledger group for each FI-relevant, non-liquid posting. The posting
can then be processed correctly in the FI-GL system. The system assigns the ledger group when you release an
account [page 365]. You use the ledger group work table to find the correct group for a certain posting. This
work table is filled by the background job Create Work Table for Ledger Group [page 555].
Prerequisites
Before you use the ledger group in a company code, you have to activate this function for this company code in
Customizing for Basic System under Default Values Edit Defaults for Accounting . You then have to link

the accounting principles defined in the FS-RI system to the ledgers in SAP Customizing. For more information,
see Prerequisites in the documentation for the background job Create Work Table for Ledger Group [page 555].

7 Master Data
● Global Accounting Units [page 287]

● Hierarchies [page 490]
7.1 Global Accounting Units
Definition
This section introduces the concept of the families and their structures, which form the framework for defining
accounting units.
Structure
Families and Treaty Classes
The top level consists of families. Each family represents an entire structure. You can define as many families as
you want.
Each family is assigned to one or more treaty class, and one or more treaty type.
This assignment determines the treaty management context in which the accounting units configured under
the nodes for a family can be used.
The treaty class indicates the type of treaty (for example, non-life), while the treaty category defines whether
the treaty is proportional or non-proportional.
The node structures are contained under the families. The second level below a family can have exactly one
node, which is the first node in a structure and always assigned to a family. This is the top node.
Each family can only reference one top node.
Nodes
For each top node, you can create several nodes at the next levels.
You can assign exactly one attribute to each node.
An attribute corresponds to a field in an existing operative database table. This restricts the available value set
for an attribute.
The available attributes are read from a special Customizing table, containing fixed attributes.
You can define a subset of these attributes and use it to define the structure. You can specify the treaty class
for which the attributes are valid.

Master Data PUBLIC 483
You can also select attributes that have already been assigned and used as “no longer available”.
You define the usable attributes in a separate Customizing activity.
Accounting Units
You can define several accounting units for each node in a family structure. The function of a node is identical
to that of a class, which defines the features of an accounting unit (object).
The features refer to the accounting unit attributes that need to be assigned values.
These are all the attributes in a substructure, from the top node down to the node for which the accounting unit
has been defined.
When you define an accounting unit, the system creates an instance (object) of the node or of the attributes to
be assigned values. You must assign values to these attributes.
You can define several accounting units for each node, but each one must have a unique name.
Each node must be assigned to at least one company code. This defines the validity area of the accounting unit.
 Note
In special cases, one of the attributes to be assigned values may be dependent on a company code. In this
case, you must specify a company code for each accounting unit in order to call up the permitted values.
Accounting Unit Value
Once you have defined an accounting unit, you must enter values for all the attributes.
You can do this either by selecting a predefined value for this attribute or by entering a number in the case of
numerical attributes. Both entry methods are mutually exclusive.
A given attribute/value combination can only be defined once for each node. In other words, you cannot define
an accounting unit twice under the same node.
This check is only necessary for the node containing the accounting units, since the accounting units under the
other nodes cannot have the same types of attributes.
7.1.1 Dialog Description
This section explains the screens and the available pushbuttons.
● Global function keys:

○ Save
○ The system saves to the database all the changes you have made so far in the entire dialog.
○ Exit
○ The system exits the program without performing any checks. If you have changed data in the dialog,
the system asks if you want to save these changes to the database.
○ Cancel
○ If a tab page is open on the right-hand side of the screen, the system closes it. If you have changed
data in the subscreen, the system asks whether you want to accept the changes. However, the data is
not yet written to the database. If the right-hand section of the screen is empty, the system asks
whether you want to save any changes you have made to the database, as for the Exit function.

484 PUBLIC Master Data
● Tree structure
The tree shows the families with their nodes, as well as the accounting units and values under these nodes.
● Pushbuttons
○ Expand
This pushbutton expands all the folders in the tree structure.
○ Collapse
This pushbutton closes all the folders in the tree structure. Expand tree: The system expands all the
folders below the selected node.
7.1.1.1 Families
Definition
The uppermost node in a tree always has the label "Families". If you double-click this entry, the system opens a
tab page for defining families on the right-hand side of the screen. The definition of a family consists of a
unique internal number, a unique ID, and a freely-definable long text. The internal number and the ID are
required fields.
Structure
Header
When you create families, the header area is empty, since there are no superior nodes.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode you can create families or change the
ID and long texts of existing families. You cannot change the internal number of existing families (primary
key).
● Delete
This pushbutton is active only in change mode. and can be used to delete existing families that do not yet
have a top node.
● Create
This pushbutton is active only in change mode. It determines the next available family number in the
sequence and writes this to the next free line in the table control.
● Translate
This pushbutton is active only in change mode. You apply this function by selecting at least one family in
the table control. This opens a dialog box, which prompts you to select the target languages. A second

7.1.1.2 Assignment of Families to Treaty Classes
Use
Before you define the top node for a family, you first have to assign the family a treaty class and treaty category.
To assign a treaty class, you double-click a family in the tree, and a tab page appears on the right-hand side of
the screen. The fields “Treaty Class” (short text) and “Treaty Type” (proportional/non-proportional) are
required fields. Once you have selected a treaty class, the system displays the corresponding long text.
Features
Header
The header area shows the short text and long text of the family for which the assignments are being made in
the table control.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode you can assign new combinations of
treaty class and treaty categories, or delete existing assignments. You cannot change the treaty class and
treaty type of existing assignments (primary keys).
● Delete
This pushbutton is active only in change mode. and can be used to delete existing entries if the family has
not yet been assigned a top node.
7.1.1.3 Nodes
If you click a family in the tree with the secondary mouse button, you can choose “Define Initial Attribute” from
the context menu to define the top node of a structure. The node itself is created implicitly by the program. All
you have to do is choose the attribute to be assigned to the top node. You select the attribute in a dialog box
containing a list of all the available attributes. Once you have defined the top node, the context menu no longer
appears when you click on this family with the secondary mouse button.
If you click a node with the secondary mouse button, the context menu offers two options. You can use the
function “Attribute at Same Level” to assign an attribute to the current node. For each node, you can assign one
attribute at the same level. If an attribute has already been assigned, this option no longer appears in the
context menu. If you choose “Attribute at Next Level”, the system implicitly creates a new node under the
current node. You then have to assign an attribute to this new node, which is done in the same dialog as for the
function “Define Initial Attribute”. The option “Attribute at Next Level” is always visible in the context menu. You
cannot assign the same attribute more than once within an ongoing structure. The system prevents this by
removing attributes that have already been used from the list of possible entries for levels lower down.
You can only define one top node per family. Below the top node and all the nodes that follow you can define as
many additional nodes as you want.

The attributes available in the list of possible entries are read from the Customizing table /MSG/RUSEAUATTR,
based on the treaty class. Therefore, the system can only determine the available attributes for a family if at
least one treaty class has been assigned to the family.
You can also delete nodes by choosing “Delete Attribute(s)” in the context menu of the tree. This option only
appears in the context menu if the node no longer has any dependent objects, such as child nodes and
accounting units.
7.1.1.4 Accounting Units
Use
When you double-click a node, the system opens a tab page for defining accounting units for this node on the
right-hand side of the screen. If the substructure of the family up to this node contains a company code-
dependent attribute, you must first assign at least one company code to the node. You do this on the
“Company Codes” tab page, which is to the right of the current tab page. If none of the attributes are
dependent on the company code, you can define the accounting units straight away.
The internal number of the accounting unit and the short text must be unique, and both fields are mandatory.
The name of the accounting unit is freely definable. The “Company Code” field is only ready for input if the set
of attributes to be assigned values contains a company code-dependent attribute. This field is then a required
field, and can only be changed if values have not yet been assigned for the accounting unit. Once values have
been assigned, the field is locked.
Features
Header
the accounting unit is being entered.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode you can create accounting units, or
change the short and long texts of existing accounting units. If the accounting units are dependent on a
company code, you can also change the assigned company code, as long as you have not yet assigned
values to the accounting unit. You cannot change the internal number of existing accounting units (primary
key).
● Delete
This pushbutton is active only in change mode and can be used to delete existing accounting units that
have not yet been used in a treaty.
● Create
This pushbutton is active only in change mode. It determines the next available accounting unit number in
the sequence and writes this to the next free line in the table control.
● Translate

This pushbutton is active only in change mode. You apply this function by selecting at least one accounting
unit in the table control. This opens a dialog box prompting you to select the target languages. A second
7.1.1.5 Company Codes
Use
When you double-click a node, the tab page with the accounting units for this node appears on the right-hand
side of the screen. To open the tab page for company codes, click the Company Codes tab page.
On this screen, you can assign company codes to the node. There are no restrictions, and you can add and
remove company codes at any time. This only changes the context in which the accounting units can be
selected (for example, in treaties).
Features
Header
the company codes are being entered.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode, you can add company codes to the
node. You cannot change the company code field in existing entries (primary key).
● Delete
This pushbutton is active only in change mode and can be used to remove existing company code
assignments.
7.1.1.6 Node Attributes
Use
When you double-click a node, the tab page with the accounting units for this node appears on the right-hand
side of the screen. To see the node attributes, click on the Node Attributes tab page.
The system displays the attribute that was assigned to the node when it was created.

Features
Header
the attributes are being displayed.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode you can delete the assigned attribute.
● Delete
This pushbutton is active only in change mode and can be used to remove the assigned attribute. You can
only delete attributes if no accounting units have yet been defined for the node.
7.1.1.7 Accounting Unit Values
Use
If you double-click an accounting unit in the tree, a tab page containing the values for this accounting unit
opens on the right-hand side of the screen.
The table control contains all the attributes in the substructure, from the top node down to the node for which
the accounting unit is being defined. The “Attribute No.” and “Attribute” fields are fixed. These are the
attributes to which values have to be assigned. Likewise, you cannot change the “Operator” field, which has the
standard default setting "=". Depending on the type of attribute, you either select a value from a dynamic list of
possible entries that is generated specifically for the attribute in question, or enter a number in the case
numerical attributes. Only one of these fields is ready for input in change mode, while the other is locked. You
must assign values to all the attributes before you can leave the tab page.
Features
Header
The header area contains the short and long texts for the family, the node attributes, and the short and long
texts for the accounting unit that is being assigned the values.
Pushbuttons
● Change
You can toggle between display and change mode. In change mode you can assign values to the attributes.
Depending on the type of attribute, either the “Value” or “Number” field is ready for input.
● Where-used list
This pushbutton opens a dialog box showing all the treaties in which the current accounting unit is used.

7.1.1.8 Translate
If you choose the Translate pushbutton on the screens for families and accounting units, a dialog box prompts
you to select the target languages. The system then calls the translation dialog, and lists the data records to be
translated in the current system language and in the target language. If a translation already exists for the
chosen target language, it is read to the table. You can then add the short and long texts for the target
languages, or change the existing entries. You cannot change the entry with the current system language.
Pushbuttons
● OK
If you select this pushbutton, the system saves the new and changed translations. However, the
translations are not written to the database until you choose Save in the main program.
7.2 Hierarchies
You can specify the following hierarchies:
● Area
● Treaty
● Treaty section
● Loss
● Statistical account
● Optional sets 1 to 4
● Program set
The hierarchies for areas and classes of business have additional value types.
End nodes are used only in areas, classes of business, and lines of business.
7.2.1 Maintaining Hierarchies
Use
You maintain the treaty section hierarchy in the hierarchy editor. This enables you to see the hierarchical
structure of the treaty section hierarchy you are currently working on in the form of a graphic.
Each hierarchy has its own transaction with the same function for all hierarchies, whereby value types are only
available for classes of business and areas, and end nodes are only used in classes of business, areas, and lines
of business.

Features
Possible actions:
● Create
For more information, see "Create Node".
● Edit
● Display
If you set the “Inversion” checkbox, the tree is inverted and the required node is displayed as the lowest level
node. This enables you to determine where the node occurs.
The following functions are available for processing hierarchies:
● Expand subtree
This system expands a node and displays the underlying nodes and end nodes.
● Collapse subtree
The system collapses a node.
● Create node
To create a new node, you must select an existing node and then choose “Create Node”. You must then
enter the internal key and short text. You can also enter a long text and a value type. You can use the “F4
Help” checkbox to determine whether the required hierarchy for this node is displayed in an input help
dialog box.
● Change node
Here you can change all the relevant settings for the node, with the exception of the internal key.
● Insert node/end node
When you choose “Insert Node/End Node”, a dialog box appears in which you can choose the node or end
node you require. To call the input search help for a node or an end node, click the input field with the
secondary mouse button. You can only choose end nodes if the hierarchies support these nodes (only for
classes of business, lines of business, and areas).
● Delete link
Here you can delete a link. Note that you can only delete the link from the hierarchy, and not the node or
end node. For example, if you delete the link between WORLD and EU, EU still exists in the database, which
means that you can add EU to this or another hierarchy at any time.
● Deactivate node
If you deactivate a node, you can no longer select this node in the system. You can only delete nodes that
do not contain other nodes. Moreover, end nodes used in other hierarchies cannot exist.
● Completeness
If you choose “Completeness”, the system displays all end nodes that are not yet used in the hierarchy. You
can assign the end nodes displayed directly to the nodes in the hierarchy. This function is useful only if the
hierarchy uses end nodes.
● Use end nodes
This enables you to go to the maintenance view for the relevant end nodes. You cannot go to the
maintenance view if the hierarchy does not support end nodes.
● Translate
Here you can translate all the nodes. To translate nodes, choose “Translate”; this takes you to the
translation screen. Then select an entry and choose Goto Translation . You can then select a
language and translate the node.

7.2.2 Class of Business Hierarchy
A class of business hierarchy depicts a rank order of individual classes of business built up from the higher-
level hierarchy with its nodes and end nodes. A class of business hierarchy is determined by its short text. This
short text is language dependent and must be unique for all class of business hierarchies.
7.2.2.1 Manage Class of Business
You use the maintenance transaction for classes of business to create, change, and display classes of business.
You call the transactions through the following menu paths.
Possible actions:
● Create/change: FS-RI Reinsurance Master Data Classes of Business Edit

● Display: FS-RI Reinsurance Master Data Classes of Business Display
7.2.2.2 Manage Class of Business Hierarchy
A class of business hierarchy contains three types of nodes. The highest node is the hierarchy node. The
hierarchy node is marked by its language-dependent short text. You use the short text to change class of
business hierarchies or select these in the search help. The node that is not a class of business is called the
“true” node. The node that has a defined class of business is called the end node. The end node has no
assigned nodes and forms the end of the branch of the class of business hierarchy.
You use the maintenance transaction for the class of business hierarchy to create, change, and display class of
business hierarchies. You call these transactions through the following menu paths.
Possible actions:
● Create: FS-RI Reinsurance Master Data Classes of Business Hierarchy Create

● Change: FS-RI Reinsurance Master Data Classes of Business Hierarchy Change
● Display: FS-RI Reinsurance Master Data Classes of Business Hierarchy Display
For a detailed description of hierarchy processing, see Maintaining Hierarchies [page 490].
7.2.3 Line of Business Hierarchy
A line of business hierarchy depicts a rank order of individual line of business nodes built up from the higher-
level hierarchy with its nodes and end nodes. A line of business hierarchy is determined by its short text. This
short text is language dependent and must be unique for all line of business hierarchies.

7.2.3.1 Maintain Line of Business
You use the maintenance transaction for lines of business to create, change, and display lines of business. You
call the transactions through the following menu paths.
Possible actions:
● Create/change: FS-RI Reinsurance Master Data Line of Business Edit

● Display: FS-RI Reinsurance Master Data Line of Business Display
7.2.3.2 Maintain Line of Business Hierarchy
A line of business hierarchy contains three types of nodes. The highest node is the hierarchy node. The
hierarchy node is marked by its language-dependent short text. You use the short text to change line of
business hierarchies or select these in the search help. The node that is not a line of business is called the
“true” node. A node that has a defined line of business is called the end node. The end node has no assigned
nodes and forms the end of the branch of the line of business hierarchy.
You use the maintenance transaction for the line of business hierarchy to create, change, and display line of
business hierarchies. You call these transactions through the following menu paths.
Possible actions:
● Create: FS-RI Reinsurance Master Data Line of Business Hierarchy Create

● Change: FS-RI Reinsurance Master Data Line of Business Hierarchy Change
● Display: FS-RI Reinsurance Master Data Line of Business Hierarchy Display
7.2.4 Area Structuring
The term “area structuring” refers to the modeling of an area hierarchy from higher-level areas (nodes) and the
areas assigned to these nodes (end nodes). An area is a region that is identified by its name; an area can
appear in more than one node (for example, Italy is in Europe and in the Mediterranean region).
 Example
● World
● Europe
○ Germany
○ France
○ Belgium
○ Austria
● America
○ South America
○ North America

7.2.4.1 Maintain Area
Possible actions:
● Create/change: FS-RI:Reinsurance Master Data Areas Edit

● Display: FS-RI:Reinsurance Master Data Areas Display
Alternatively, you can also call the basic functions through the corresponding transaction code:
● Create/change: /MSG/RGBPF
● Display: /MSG/RGBAN
7.2.4.2 Maintain Area Hierarchy
Possible actions:
● Create: FS-RI:Reinsurance Master Data Areas Hierarchy Create

● Change: FS-RI:Reinsurance Master Data Areas Hierarchy Change
● Display: FS-RI:Reinsurance Master Data Areas Hierarchy Display
● Create: /MSG/RGB01
● Change: /MSG/RGB02
● Display: /MSG/RGB03
7.2.5 Treaty Hierarchy
The treaty hierarchy allows you to group reinsurance treaties by user-defined characteristic values at treaty
header level. You can group the individual characteristic values hierarchically. You assign a treaty to a
characteristic value for a treaty hierarchy on the Header Data tab page in the treaty transaction. You can assign
more than one treaty to a characteristic value.
7.2.5.1 Maintain Treaty Hierarchy
You use the maintenance transaction for the treaty hierarchy to create, change, and display treaty hierarchies.
Possible actions:
● Create: FS-RI:Reinsurance Master Data Treaty Hierarchy Create

● Change: FS-RI:Reinsurance Master Data Treaty Hierarchy Change
● Display: FS-RI:Reinsurance Master Data Treaty Hierarchy Display

● Create: /MSG/RVT01
● Change: /MSG/RVT02
● Display: /MSG/RVT03
7.2.6 Treaty Section Hierarchy
The treaty section hierarchy allows you to group reinsurance treaty sections by user-defined characteristic
values at treaty section level. You can group the individual characteristic values hierarchically. You assign a
treaty section to a characteristic value for a treaty section hierarchy on the Section tab page in the treaty
transaction. You can assign more than one section from different treaties to a characteristic value.
7.2.6.1 Maintain Treaty Section Hierarchy
You use the maintenance transaction for the treaty section hierarchy to create, change, and display treaty
section hierarchies.
In change and display mode, the initial screen does not have the "Default" group box.
Possible actions:
● Create: FS-RI:Reinsurance Master Data Treaty Section Hierarchy Create

● Change: FS-RI:Reinsurance Master Data Treaty Section Hierarchy Change
● Display: FS-RI:Reinsurance Master Data Treaty Section Hierarchy Display
● Create: /MSG/RVB01
● Change: /MSG/RVB02
● Display: /MSG/RVB03
7.2.7 Loss Hierarchy
The loss hierarchy allows you to group losses by user-defined characteristic values. You can group the
individual characteristic values hierarchically. You assign a loss to a characteristic value for a loss hierarchy on
the Loss Processing tab page in the loss transaction. You can assign more than one loss to a characteristic
value.

7.2.7.1 Maintain Loss Hierarchy
You use the maintenance transaction for the loss hierarchy to create, change, and display loss hierarchies.
Possible actions:
● Create: FS-RI:Reinsurance Master Data Loss Hierarchy Create

● Change: FS-RI:Reinsurance Master Data Loss Hierarchy Change
● Display: FS-RI:Reinsurance Master Data Loss Hierarchy Display
● Create: /MSG/RSC01
● Change: /MSG/RSC02
● Display: /MSG/RSC03

8 Information System
The FS-RI information system contains the following tools for evaluating data:
● ABAP Query
● Report Painter
You can call these tools on the SAP Easy Access screen under Information Systems Ad Hoc Reports
Tools or under Reinsurance Information System Tools .
You can still run various predefined reports or evaluations. All reports and evaluations contained in the product
scope are templates that must be adjusted during implementation using the available statistical tools to meet
specific customer requirements regarding layout and content.
● Funds
● RI
● Treaty
You can call these on the SAP Easy Access screen under Reinsurance Information System Reports .
“Funds” contains an evaluation that serves as a template and that was created with the help of Report Writer.
This report is a template only and can be copied and expanded accordingly.
“RI” contains the evaluations “RI Statistics” and “Fund Statistics”. You can change the layout and content of
these evaluations in Customizing.
The following evaluations are based on queries. The name of the corresponding query is in brackets. You can
find a more detailed description of the evaluation under “Query”.
“Treaty” contains the following evaluations:
● /MSG/VTGM – Treaties by Broker (VTG_MAKLER)

● /MSG/VTGZ – Treaties by Cedent (VTG_ZEDENT)
● /MSG/VVTG – Distribution Plan by Treaty (VERTL_VTG)
● /MSG/VGES – Distribution Plan by Company (VERTL_GES)
“Business Partner” contains the following evaluations:
● /MSG/GES1 – Cedent/Reinsurer (GESELLSCHAFT1)

● /MSG/GES2 – Brokers (GESELLSCHAFT2)
● /MSG/GES3 – Cedent/Reinsurer and Broker (GESELLSCHAFT3)
● /MSG/GES4 – Cedent/Reinsurer and/or Broker (GESELLSCHAFT4)
● /MSG/GES5 – Neither Cedent/Reinsurer nor Broker (GESELLSCHAFT5)

Information System PUBLIC 497
8.1 SAP Query
You use SAP Query to evaluate and create a list of data. You do not need any ABAP programming knowledge to
use this tool.
A query must always be based on one InfoSet (previously known as a functional area), so that you are actually
able to perform evaluations. An InfoSet defines the fields and tables that the query can access. In turn, a logical
database, which is responsible for supplying the data, generally underlies an InfoSet.
Programming knowledge is required to set up the logical database and possibly also to define the InfoSet.
General Notes
The queries and InfoSets shown below are provided as examples or ideas only. You can make individual
changes to queries, InfoSets and logical databases, or create new ones.
You can find the exact procedure for creating logical databases, InfoSets, and SAP queries in the online help for
the SAP system.
The following queries are defined by default and assigned to the FS-RI user group:
● The queries GESELLSCHAFT1 – GESELLSCHAFT5 list all companies that are defined in the FS-RI system
and have or do not have a specific role.
○ GESELLSCHAFT1 – This evaluation provides a list of all companies that appear as cedent and/or
reinsurer but not as broker.
○ GESELLSCHAFT2 – This list provides an overview of all brokers defined in the FS-RI system that have
no cedent or reinsurance function.
○ GESELLSCHAFT3 – This list provides an overview of all companies that can appear as cedents,
reinsurers, or brokers.
○ GESELLSCHAFT4 – This lists all companies that are defined either as cedent/reinsurer or as broker. It
also lists all companies that can represent both functions.
○ GESELLSCHAFT5 – You can use this query to evaluate companies that are not authorized as either
cedent/reinsurer or as broker.
● Query VERTL_GES lists all companies and the treaties in which this company participates. You can restrict
the number of companies using selection criteria.
● Query VERTL_VTG lists the treaties and the companies that participate in this treaty. You can restrict the
number of treaties using selection criteria.
● Query VTG_MAKLER lists all brokers and the treaties that they have brokered.
● Query VTG_ZEDENT lists all cedents and their treaties.
You can get an overview of these queries in the menu “SAP Query” by selecting the user group “FS-RI”. You can
configure the user group in the menu under Edit Other User Group .
As of Release 4.64, you can easily link the lists generated with SAP queries to the treaty, if corresponding fields
related to the treaty are used in the lists.
To do this, when you create or change a query you must assign report /MSG/R_BRANCH_FROM_QUERY to this
query as the target report. You do this by choosing Goto Report Assignment Insert Line (F6) Other
Report Type ABAP Report .

498 PUBLIC Information System
8.2 Report Painter/Report Writer
You have created a funds evaluation as an example report using Report Writer. This report is a template only
and can be copied and expanded accordingly.
Library: ZDP
Report: ZDEPOT
You can call report ZDEPOT in the information system in the FS-RI system under “Other” -> “Information
System” -> “Funds” - > “Evaluation of Funds”.
You can also call this report under “Other” -> “Information System” -> “Report Painter”.
In the “Report Painter” menu, choose “Report Writer” -> “Report” -> “Display”. On the “Display Report: Initial
Screen”, enter the library and report specified above.
You trigger the evaluation by choosing “Report” -> “Execute”. The “Execute Report Group: Initial Screen”
appears; the system assigns report group ZBDP to report ZDEPOT.
If you choose “Execute”, the system displays the result of the evaluation.
You can also call the report through the activity group under “Information System” -> “Reports” -> “Funds” ->
“Evaluation of Funds”.
8.3 Fund Statistics
This is the basic concept for evaluating funds in SAP Reinsurance Management for SAP S/4HANA (FS-RI).
To achieve maximum flexibility when you evaluate the funds held, you can use parameters and tables to control
extensively the processes performed in this function.
The list of evaluations is defined by an RI model that you create according to RI statistics.
This includes:
● Definition of an RI model
● Description of the value lines
● Assignment of entry codes (fund types) to the value lines
● Definition of totals
● Definition of division operations to determine percentages
● Definition of a fund request
● Creation of request parameters, such as model, financial year, sort and selection criteria
Flow of Data During the Evaluation of Funds
You enter a posting using the accounting function.
When you release the account, the system transfers the data to the list of evaluations.

When you request an RI evaluation, the system reads the following data:
● Parameters of the RI statistical request

● Line texts of the selected model
● Table of the entry codes assigned to the lines of the model
● Calculation rules for totals
● Calculation rules for percentages
● Posting data, based on the sort and selection criteria entered in the request (it may also read additional
exchange rate dates if data is to be evaluated at special exchange rates)
● Any exchange rates for the target currency
This data is processed together and output as a print file. The system first translates every value to the target
currency, using the desired exchange rate. It then assigns the value to the determined RI statistical row. Next, it
calculates the totals rows and the absolute difference values. Finally, it calculates the percentages and relative
differences.
You can either view the print file created from this data online or print this file out.
RI Model
An RI model contains all the information assigned to a model.
Each model is identified by a number and a name. This is used to generate the RI evaluation list (evaluation of
funds) in different variants. All the rules needed for an RI evaluation are created for each model.
You use the RI model number to define different RI models (the RI model number is a key).
The name of the RI model uniquely describes the RI model using text entered by the user (maximum of 40
characters).
8.3.1 Menu Path
Information System Reports RI Fund Statistics
If you select this radio button, the system uses the original currency as the base currency.
● Account currency
If you select this radio button, the system uses the account currency as the base currency.
● Currency conversion
If you set this checkbox, the system translates the currencies into the local or target currency. If you do not
set this checkbox, the system displays amounts in the original or account currency, depending on the radio
button selected. Note that in this case the result is only meaningful if the data is also sorted by the
corresponding currency. The system checks whether this is the case; if not, it displays an error message.

8.3.3 Currency Translation
● Exchange rate type for local currency

You must enter an exchange rate type for translating a foreign currency into the local currency.
In newer releases, the system reads this value from a table of default values.
● Target currency
If you enter a target currency, the system translates all amounts into this currency according to the
exchange rates for the financial years with postings. This enables you to create statistics in a foreign
currency. However, to use this function you must enter an exchange rate for every financial year with
postings.
● Exchange rate type for target currency
You must enter an exchange rate type for translating into a target currency (if you have entered a target
currency).
● Translation date
If you enter a translation date, the system translates all amounts according to the exchange rate in effect
on the translation date.
8.3.4 Restricting the List of Evaluations
The following section describes how you can create the evaluation using a self-defined dataset.
● Selection criteria
In this group box, you can enter criteria for the specified selection fields. These are then used in the
database query. This allows you to restrict the evaluation to special “dataset” views, depending on the
request.
You can open a dialog box to enter values. The values entered are used to select data.
● Sort criteria
Summarization Levels
You can sort the list of reinsurance funds to a maximum of five levels.
In the “Sort Criterion 1” to “Sort Criterion 5” fields, you enter the fields according to which you want to sort
data.
1. If any of these are the same as the 15 fields in the “Selection Criteria” group box, you can enter the
number preceding the field in the line.
2. If you want to sort according to another field in the /MSG/RWKDEPOT table, you must enter the name
of the field in the line.
3. If you want to sort according to a field in another table (which must be connected through a “join” to
the /MSG/RWKDEPOT table), enter the name of this table before the field name (in the form
TABLENAME-FIELDNAME).
 Caution
You cannot sort according to a field that does not belong to /MSG/RWKDEPOT or a table
connected to it through a “join”. You can sort by cedent (for assumed business) or reinsurer (for
ceded business) by sorting by partners. This is the cedent when incoming business is selected, and
the reinsurer or retrocessionaire for outgoing business.
● Selection enhancements

You can use a selection enhancement to further restrict the data being evaluated. You can use this
selection enhancement to access datasets for other tables and so include these in the evaluation.
Selection enhancements are tables or views that you can enter for this purpose in Customizing for FS-RI
Reinsurance under Basic System RI Statistics Define Selection Enhancements .
 Note
To be able to enter selection enhancements, you need to be authorized to change Customizing and, if
necessary, to define customer-specific views for use as selection enhancements. You also need to
know how to maintain views.
To use the selection enhancement option, make a selection in the field of the same name from the values
entered in the above Customizing activity.
When you have selected a selection enhancement, you can define selection criteria under “Enhanced
Selection Criteria” for up to ten of the fields entered in the selection enhancement table or view.
 Note
No programming knowledge is required to use and configure the selection enhancements. However,
knowledge of the FS-RI data model is an advantage.
8.3.5 Program Variants
With such extensive selection screens, it is advantageous to work with variants. You can use these program
variants, which can also be saved, to adjust the entry screen to meet specific needs. For more information, see
the SAP documentation on “Report Variants”.
8.4 RI Statistics
This is the basic concept for evaluating reinsurance statistics in SAP Reinsurance Management (FS-RI).
To achieve maximum flexibility when you evaluate reinsurance statistics, you can use parameters and tables to
control extensively the processes performed in this function.
This includes:
● Definition of an RI statistics model

● Assignment of entry codes to the value lines
● Definition of an RI statistical request
Flow of Data During the Evaluation of Reinsurance Statistics

When you request an RI evaluation, the system reads the following data:
● Parameters of the RI statistical request

● Posting data, based on the sort and selection criteria entered in the request
● Any additional exchange rate dates (if data is to be evaluated at special exchange rates)
currency, using the desired exchange rate. It then assigns the value to the determined RI evaluation row. Next,
it calculates the totals rows and the absolute difference values. Finally, it calculates the percentages and
relative differences.
RI Statistics Model
An RI statistics model contains all the information assigned to a model.
Each model is identified by a number and a name. This is used to generate the evaluation list in different
variants. All the rules needed for RI statistics are created for each model.
You use the RI statistics model number to define different RI statistics models (the RI statistics model number
is a key).
The name of the RI statistics model uniquely describes the RI statistics model using text entered by the user
(maximum of 40 characters).
8.4.1 Menu Path
Information System Reports RI RI Statistics
8.4.2 Information About Column Content
You can request the list of reinsurance statistics with various column settings.
[1] Financial Year/Accounting Year
The system shows the financial years n until < n-2 (for example, 1989, 1988, 1987, <1987 if 1989 was entered as
the financial year).
Or:
The system shows the accounting years n until < n-2 (for example, 1988, 1987, 1986, <1986 if 1988 was entered
as the accounting year). You can display at least 4 to 15 years for the financial years and the accounting years.

[2] Distribute Financial Year to Accounting Years
In columns 4 to 15, the system shows the accounting years for which postings were made in a financial year
(provided you have entered the financial year):
Column 1 contains all postings with the same accounting year as the financial year.
Column 2 contains those postings with the same accounting year as the financial year minus 1.
...
and
[3] Distribute Accounting Year to Financial Years
In columns 4 to 15, the system shows the financial years in which postings were made to an accounting year
(provided you have entered the accounting year):
Column 1 contains all postings with the same financial year as the accounting year.
Column 2 contains those postings with the same financial year as the accounting year plus 1.
...
[4] Distribute Accounting/Financial Year to Underwriting Years
In columns 4 to 15, the system shows the underwriting years for which postings were made in a financial or
accounting year (provided you have entered either the financial or accounting year):
Column 1 contains all postings with the same underwriting year as the financial or accounting year.
Column 2 contains all postings with the same underwriting year as the financial or accounting year minus 1.
...
[5] Distribute Accounting/Financial Year to Occurrence Years
This selection distributes the values of a financial or accounting year among 4 to 15 occurrence years.
For example, if the accounting or financial year is 2001:
Column 1 contains the values for the occurrence year that equals the requested accounting or financial year:
occurrence year = 2001.
Column 2 contains the values for the occurrence year that is 1 year before the requested accounting or
financial year: occurrence year = 2000.
Column 3 contains the values for the occurrence year that is 2 years before the requested accounting or
...

Column 15 contains the values for the occurrence years that are more than 15 years before the requested
accounting or financial year: occurrence year < 1987.
[6] 1-3-5-10 View
Column 1 contains the values for the specified financial or accounting year.
Column 2 contains the cumulative values of years 0 to 2 from the entered year backwards.
[7] Divide into Four Quarters
This selection distributes the values of a financial or accounting year to four quarters:
Column 1 contains the values for accounting periods that end in the first quarter.
Column 2 contains the values for accounting periods that end in the second quarter.
Column 3 contains the values for accounting periods that end in the third quarter.
Column 4 contains the values for accounting periods that end in the fourth quarter.
[8] Assumed/Retrocession/Net
This list enables you to perform a net evaluation for assumed business. You choose the sort criteria so that
retrocession values are also present for the respective gross values. You must not sort by treaty.
[9] Three Years and Sum Total
Three columns are filled according to financial or accounting year; the fourth column represents the sum of the
three columns.
[10] One Column for Totals
The system shows all the values for a year in one column.
[11] Revaluation
The system values amounts using the exchange rates at the time at which the account was released and the
year-end prices corresponding to the selected exchange rate.
It calculates the difference between these valuations and displays this as a third value.
Column 1 contains the amounts valued using the mid-year exchange rates.
Column 2 contains the amounts valued using the year-end exchange rates.
Column 3 contains the difference between the two values.
● You must enter the financial year if you have not entered an accounting year.
● You must enter the accounting year if you have not entered a financial year.
● You can enter the underwriting year if the action is “TK” or “TJ”. If this is not available, the financial or
accounting year entered is set as the underwriting year.
● If you do not enter an occurrence year, the system uses the underwriting year.
● Years displayed
In the column models 1 to 5, you can choose to display 4 to 15 years and so restrict the list width.
● Treaty category (assumed/ceded)

If you enter “1”, the system selects assumed treaties only; if you enter “2”, the system selects ceded
treaties only. If you enter “3”, the system selects both treaty categories and multiplies the values of the
ceded treaties by -1.
● Treaty class
You can distinguish between non-life and life reinsurance treaties when you select the data. You do this by
selecting either “Life”, “Non-Life”, or the combination “Life and Non-Life” in the “Treaty Class” field.
8.4.2.1 Currency Handling
8.4.2.2 Currency Translation
You only need to make entries in these fields if you have set the “Currency Translation” checkbox.
Exchange rates are calculated when the original exchange rate differs from the exchange rate for the local
currency or target currency. You can perform currency translations for a specific exchange rate date and type.
To translate the original currency into the local currency, you can select a translation date (exchange rate date)
through the “Exchange Rate Selection” or “Exchange Rate Year” fields.
An exchange rate is entered for the exchange rate type (usually the closing rate for a year) for this translation in
advance in the exchange rate table for the relevant year. You must enter this exchange rate type in the
“Exchange Rate Type for Local Currency” field. In newer releases, you enter the exchange rate type for this
translation in a table of default values in Customizing. The system reads the values into the program from this
table.
● Exchange rate selection

You can make the following entries:
“O”: The exchange rates for the original accounting years are used.
“Z”: The exchange rates for the underwriting years are used.
“B”: The exchange rates for the financial years are used (this is the default value); this is selected if you do
not enter any data.
“A”: The exchange rates at the time at which the account is released are used.
● Exchange rate year
If you enter an exchange rate year, the system translates all foreign currency amounts into the local
currency using this year's exchange rates. The system then overwrites the year selected in the “Exchange
Rate Selection” field with the exchange rate year entered.

Opening and closing reserves are valued differently - always using the closing rate of the financial year.You
must enter the exchange rate type (see "Exchange rate type for reserves").
You must enter an exchange rate type for translating into the local currency. In newer releases, the system
reads this value from a table of default values.
● Exchange rate type for reserves
You must enter an exchange rate type for translating or valuating reserves. In newer releases, this value is
also stored in a table of default values.
● Target currency
currency, for example in Swiss francs. However, to use this function you must enter an exchange rate for
every financial or accounting year with postings. It is therefore best to use it only for column settings that
include only one financial year. If exchange rates do not exist for a specific number of financial years, you
can request the list of reinsurance statistics for specific financial years by entering an additional condition.
You must enter an exchange rate type if you have entered a target currency.
8.4.2.3 Restricting the List of Evaluations

First choose Selection/Sort Criteria on the main selection screen.
To restrict the dataset according to a specific criterion, select the corresponding criterion in the dialog box.
Choose “Sort in Ascending Order” or “Sort in Descending Order” to display the list of selection and sort criteria
in alphabetical order. If you enter a ranking order of 1 to 5 in the “Sort No.” field, the system sorts the dataset by
a criterion.
In this group box, you can enter criteria for the specified selection fields. These are then used in the
request.
You can open a dialog box to enter values. The values entered are used to select data.
 Note
When you have selected a selection enhancement, you can define selection criteria under “Enhanced
Selection Criteria” for up to ten of the fields entered in the selection enhancement table or view.

 Note
you need a sound knowledge of the FS-RI data model.
● Additional criteria
Accounting principle
If you select an accounting principle you can display statistics based on the different sets of books in a
company (for example, German HGB, US GAAP, IAS, cedent view). The accounting principle also controls
the base year underlying the evaluation (financial/accounting year). This replaces the “For Previous Year”
function used in previous releases. Simply select an accounting principle.
The system automatically determines the base year for the accounting principle using the settings in
Customizing. The statistics only show the aggregated entry codes that have been assigned to the
accounting principle.
Accounting unit
You can use the global accounting unit as a selection and sort criterion.
8.4.2.4 List Layout
● Striped
The lines are printed in rows.
● Hide zero rows
The zero rows are hidden in the evaluation.
Supplements
The list of reinsurance statistics recognizes the following result rows:
● Single rows (PY, FY)

The values for the single rows are obtained by adding the values read. The way values are entered depends
on the assignments in the entry code assignment table.
● Totals rows (TR)
The values for the totals rows are obtained by adding single and/or totals rows.
● Quotient row (QR%)
The values for the percentage rows are obtained by dividing any other desired value rows and multiplying
by 100.
● Cross percentage rows (QP)
The values for the cross percentage rows show the difference between the above-lying values. This
difference is always in relation to the column to the right.
 Example
1990 1989 1988
Premium 250,000 150,000 100,000
Difference 66.66% 50.00% 0.00

1990 1989 1988
Losses incurred 240,000 160,000 100,000
Difference 50.00% 60.00% 0.00
These percentages are calculated only for the two left columns, since a value that can be used as a
100% base is found in the far-right column in exceptional cases only.
● Cross difference rows (QD)

If you enter QD as the usage indicator, this is a row in which the change in the previous row for a value
(compared to the value printed to the right in the same row) is output as an absolute value. In this case, the
row cannot be used when you assign entry codes.
The values for these rows show the difference between the above-lying values. This difference is always in
relation to the column to the right.
 Example
1990 1989 1988
Premium 250,000 150,000 100,000
Difference 100,000 50,000 0.00
● Exchange rate difference rows (ER)

The values in these rows show the difference between the closing reserves and the opening reserves in the
three rows above. As such, they are used to show exchange rate differences. To use rows in this way, you
must enter ER as the usage indicator. This row type only becomes effective when the RI model is requested
with the action TJ or TK.
 Example
1990 1989 1988
Opening loss reserve 250,000 200,000 100,000
Closing loss reserve for 120,000 100,000 90,000

previous year
Closing loss reserve for fi- 120,000 120,000 120,000

nancial year
Difference 30,000 10,000
It is essential that these four rows are defined in this order one after another.

8.4.2.5 Program Variants
8.5 Statistics
The “Statistics” report contains the same functions as for reinsurance statistics, with an additional screen for
selecting the data source. You can evaluate not only the statistics table in Basic System but also the statistics
table in Risk Manager (Non-Life).
The only difference to reinsurance statistics is that the data selection screen comes before the main selection
screen. The same Customizing functions apply to the evaluation itself as to reinsurance statistics.
This is the basic concept for evaluating statistics in SAP Reinsurance Management (FS-RI).
To achieve maximum flexibility when you evaluate statistics, you can use parameters and tables to control
extensively the processes performed in this function.
This includes:
● Definition of an RI statistics model

● Assignment of entry codes to the value lines
● Definition of an RI statistical request
Flow of Data During the Evaluation
When you request an evaluation, the system reads the following data:
● Parameters of the evaluation request

● Posting data, based on the sort and selection criteria entered in the request
● Any additional exchange rate dates (if data is to be evaluated at special exchange rates)
currency, using the desired exchange rate. It then assigns the value to the determined evaluation row. Next, it
calculates the totals rows and the absolute difference values. Finally, it calculates the percentages and relative
differences.

Statistics Model
A statistics model contains all the information assigned to a model. Each model is identified by a number and a
name. This is used to generate the evaluation list in different variants. All the rules needed for statistics are
created for each model.
You use the statistics model number to define different statistics models (the statistics model number is a key).
The name of the statistics model uniquely describes the statistics model using text entered by the user
(maximum of 40 characters).
8.5.1 Menu Path
Information System Reports RI Statistics
8.5.2 Selecting the Data Source
You can evaluate the statistics dataset for Basic System (table /MSG/RWKLISTEC) or the statistics dataset for
Risk Manager (Non-Life) (table /MSG/HWKLISTEC).
Once you have selected the statistics table, you can use almost all the fields in the selected table as sort and
selection criteria.
8.5.3 Information About Column Content
You can request the list of statistics with various column settings.
[1] Financial Year/Accounting Year
The system shows the financial years n until < n-2 (for example, 1989, 1988, 1987, <1987 if 1989 was entered as
the financial year).
Or:
The system shows the accounting years n until < n-2 (for example, 1988, 1987, 1986, <1986 if 1988 was entered
as the accounting year). You can display at least 4 to 15 years for the financial years and the accounting years.
[2] Distribute Financial Year to Accounting Years
In columns 4 to 15, the system shows the accounting years for which postings were made in a financial year
(provided you have entered the financial year):
Column 1 contains all postings with the same accounting year as the financial year.

...
[3] Distribute Accounting Year to Financial Years
In columns 4 to 15, the system shows the financial years in which postings were made to an accounting year
(provided you have entered the accounting year):
Column 1 contains all postings with the same financial year as the accounting year.
...
[4] Distribute Accounting/Financial Year to Underwriting Years
In columns 4 to 15, the system shows the underwriting years for which postings were made in a financial or
accounting year (provided you have entered either the financial or accounting year):
Column 1 contains all postings with the same underwriting year as the financial or accounting year.
...
[5] Distribute Accounting/Financial Year to Occurrence Years
This selection distributes the values of a financial or accounting year among 4 to 15 occurrence years.
For example, if the accounting or financial year is 2001:
Column 1 contains the values for the occurrence year that equals the requested accounting or financial year:
occurrence year = 2001.
Column 2 contains the values for the occurrence year that is 1 year before the requested accounting or
Column 3 contains the values for the occurrence year that is 2 years before the requested accounting or
...
Column 15 contains the values for the occurrence years that are more than 15 years before the requested
accounting or financial year: occurrence year < 1987.
[6] 1-3-5-10 View
Column 1 contains the values for the specified financial or accounting year.

[7] Divide into Four Quarters
This selection distributes the values of a financial or accounting year to four quarters:
Column 1 contains the values for accounting periods that end in the first quarter.
Column 2 contains the values for accounting periods that end in the second quarter.
Column 3 contains the values for accounting periods that end in the third quarter.
Column 4 contains the values for accounting periods that end in the fourth quarter.
[8] Assumed/Retrocession/Net
This list enables you to perform a net evaluation for assumed business. You choose the sort criteria so that
retrocession values are also present for the respective gross values. You must not sort by treaty.
[9] Three Years and Sum Total
Three columns are filled according to financial or accounting year; the fourth column represents the sum of the
three columns.
[10] One Column for Totals
The system shows all the values for a year in one column. [11] Revaluation The system values amounts using
the exchange rates at the time at which the account was released and the year-end prices corresponding to the
selected exchange rate.
It calculates the difference between these valuations and displays this as a third value.
Column 1 contains the amounts valued using the mid-year exchange rates.
Column 2 contains the amounts valued using the year-end exchange rates.
Column 3 contains the difference between the two values.
● You must enter the financial year if you have not entered an accounting year.
● You must enter the accounting year if you have not entered a financial year.
● You can enter the underwriting year if the action is “TK” or “TJ”. If this is not available, the financial or
accounting year entered is set as the underwriting year.
● If you do not enter an occurrence year, the system uses the underwriting year.
● Years displayed: In the column models 1 to 5, you can choose to display 4 to 15 years and so restrict the list
width.
● Treaty category (assumed/ceded)
If you enter “1”, the system selects assumed treaties only; if you enter “2”, the system selects ceded
treaties only. If you enter “3”, the system selects both treaty categories and multiplies the values of the
ceded treaties by -1.
● Treaty class (Basic System only)
You can distinguish between non-life and life reinsurance treaties when you select the data. You do this by
selecting either “Life”, “Non-Life”, or the combination “Life and Non-Life” in the “Treaty Class” field.
8.5.3.1 Currency Handling

8.5.3.2 Currency Translation
You only need to make entries in these fields if you have set the “Currency Translation” checkbox.
Exchange rates are calculated when the original exchange rate differs from the exchange rate for the local
currency or target currency. You can perform currency translations for a specific exchange rate date and type.
To translate the original currency into the local currency, you can select a translation date (exchange rate date)
through the “Exchange Rate Selection” or “Exchange Rate Year” fields.
An exchange rate is entered for the exchange rate type (usually the closing rate for a year) for this translation in
advance in the exchange rate table for the relevant year. You must enter this exchange rate type in the
“Exchange Rate Type for Local Currency” field. In newer releases, you enter the exchange rate type for this
translation in a table of default values in Customizing. The system reads the values into the program from this
table.
● Exchange rate selection

You can make the following entries:
“O”: The exchange rates for the original accounting years are used.
“Z”: The exchange rates for the underwriting years are used.
“B”: The exchange rates for the financial years are used (this is the default value); this is selected if you do
not enter any data.
“A”: The exchange rates at the time at which the account is released are used.
● Exchange rate year
If you enter an exchange rate year, the system translates all foreign currency amounts into the local
currency using this year's exchange rates. The system then overwrites the year selected in the “Exchange
Rate Selection” field with the exchange rate year entered. Opening and closing reserves are valued
differently - always using the closing rate of the financial year. You must enter the exchange rate type (see
"Exchange rate type for reserves").
You must enter an exchange rate type for translating into the local currency. In newer releases, the system
reads this value from a table of default values.
● Exchange rate type for reserves
You must enter an exchange rate type for translating or valuating reserves. In newer releases, this value is
also stored in a table of default values.
● Target currency
currency, for example in Swiss francs. However, to use this function you must enter an exchange rate for
every financial or accounting year with postings. It is therefore best to use it only for column settings that

include only one financial year. If exchange rates do not exist for a specific number of financial years, you
can request the list of reinsurance statistics for specific financial years by entering an additional condition.
You must enter an exchange rate type if you have entered a target currency.
8.5.3.3 Restricting the List of Evaluations
First choose Selection/Sort Criteria on the main selection screen.
To restrict the dataset according to a specific criterion, select the corresponding criterion in the dialog box.
Choose Sort in Ascending Order or Sort in Descending Order to display the list of selection and sort criteria in
alphabetical order. If you enter a ranking order of 1 to 5 in the Sort No. field, the system sorts the dataset by a
criterion.
On this selection screen, you can enter criteria for the specified selection fields. These are then used in the
request.
You can choose the pushbutton to the right of the field to open a dialog box to enter values. The values
entered are used to select data. For more information, see Selection Options.
● Sort criteria
You can sort the list of reinsurance statistics to a maximum of five levels. In the Sort No. entry fields, you
enter the ranking number according to which the sort is conducted.
Sort criteria are predetermined by certain entries on the main selection screen. In the case of incremental
statistics, for example, the system automatically sorts using the occurrence or underwriting year as the
fifth sort criterion. If you have not set the Currency Translation checkbox, the system assigns the ranking
order 1 to the account currency or the original currency.
You can sort by cedent (for assumed business) or reinsurer (for ceded business) by sorting by partners.
This is the cedent when incoming business is selected, and the reinsurer or retrocessionaire for outgoing
business.
 Note
When you have selected a selection enhancement, you can define selection criteria under Enhanced
Selection Criteria for up to ten of the fields entered in the selection enhancement table or view.

 Note
knowledge of the FS-RI data model is an advantage.
● Additional criteria
Accounting principle
If you select an accounting principle you can display statistics based on the different sets of books in a
company (for example, German HGB, US GAAP, IAS, cedent view). The accounting principle also controls
the base year underlying the evaluation (financial/accounting year). This replaces the For Previous Year
function used in previous releases. When you had to run an evaluation before FS-RI Release 4.71, you were
required to enter an accounting year and also set the checkbox for the previous year comparison. Now, you
have to select an accounting principle. The system automatically determines the base year for the
accounting principle using the settings in Customizing.
The statistics only show the aggregated entry codes that have been assigned to the accounting principle.
Accounting unit
You can use the global accounting unit as a selection and sort criterion.
8.5.3.4 List Layout
● Striped
The lines are printed in rows.
● Hide zero rows
The zero rows are hidden in the evaluation.
Supplements
The list of reinsurance statistics
recognizes the following result rows:
● Single rows (PY, FY)

The values for the single rows are obtained by adding the values read. The way values are entered depends
on the assignments in the entry code assignment table.
● Totals rows (TR)
The values for the totals rows are obtained by adding single and/or totals rows.
● Quotient row (QR%)
The values for the percentage rows are obtained by dividing any other desired value rows and multiplying
by 100.
● Cross percentage rows (QP)
The values for the cross percentage rows show the difference between the above-lying values. This
difference is always in relation to the column to the right.
 Example
1990 1989 1988
Premium 250,000 150,000 100,000

1990 1989 1988
Difference 66.66% 50.00% 0.00
Losses incurred 240,000 160,000 100,000
Difference 50.00% 60.00% 0.00
These percentages are calculated only for the two left columns, since a value that can be used as a
100% base is found in the far-right column in exceptional cases only.
● Cross difference rows (QD)

If you enter QD as the usage indicator, this is a row in which the change in the previous row for a value
(compared to the value printed to the right in the same row) is output as an absolute value. In this case, the
row cannot be used when you assign entry codes.
The values for these rows show the difference between the above-lying values. This difference is always in
relation to the column to the right.
 Example
1990 1989 1988
Premium 250,000 150,000 100,000
Difference 100,000 50,000 0.00
● Exchange rate difference rows (ER)

The values in these rows show the difference between the closing reserves and the opening reserves in the
three rows above. As such, they are used to show exchange rate differences. To use rows in this way, you
must enter ER as the usage indicator. This row type only becomes effective when the RI model is requested
with the action TJ or TK.
 Example
1990 1989 1988
Opening loss reserve 250,000 200,000 100,000
Closing loss reserve for 120,000 100,000 90,000

previous year
Closing loss reserve for fi- 120,000 120,000 120,000

nancial year
Difference 30,000 10,000
It is essential that these four rows are defined in this order one after another.

8.5.3.5 Program Variants

9 Background Processing
Use
For an introduction to background processing and for information about how to schedule background jobs, see
SAP Help Portal under SAP Business Suite SAP ERP Central Component SAP EHP 5 for SAP ERP 6.0
Programming with the Background Processing System (BC-CCM-BTC) .
Features
Background processing automates routine tasks and helps you optimize your organization's computing
resources.
During background processing, you instruct the system to run programs for you. Background processing
enables you to run long-running or resource-intensive programs at times when the system load is low. It also
lets you delegate to the system the task of running reports or programs. Your dialog sessions are not tied up,
and reports that run in the background are not subject to the dialog-step runtime limit that applies to
interactive sessions.
9.1 Control Background Jobs
You use the standard function, Schedule Manager [page 520], to organize periodic processing.
You call Schedule Manager as follows:
● In the FS-RI initial menu under FS-RI: Reinsurance Periodic Processing

● Using transaction SCMA
9.1.1 Task Lists
Definition
In Schedule Manager you can define task lists that group the background jobs that you need regularly in a list.
The task list /MSG/FSRI0 is part of the scope of delivery of SAP Reinsurance Management for SAP S/4HANA
(FS-RI) and contains the standard background jobs of your FS-RI system in a structured form.
Alternatively, the task list /MSG/ISRI0 is available.

Background Processing PUBLIC 519
Use
When you start Schedule Manager for the first time, the system loads the SAP sample task list 0-SAP-DEMO.
You can select the required task list under Task List Other Task List . The most recently selected task list
is stored in your user parameters.
You can use the task lists as delivered; you can also copy or change them or create different task lists for the
different employee roles in your company.
 Recommendation
If you want to use a changed version of a task list, copy the task list and change the copy. This means that
your task list is not overwritten should you want to re-import the task list at a later date.
Background Jobs Contained in Task List
The task list /MSSG/FSRI0 contains all the background jobs that are recommended for your current release.
If you have upgraded from an earlier FS-RI release, the task list /MSG/FSRI0 may not contain background jobs
that you used previously. In this case, the functions of the background jobs no longer contained in the task list
are incorporated into other background jobs in the current version.
For more information, see the documentation for background jobs or ask your FS-RI consultant.
9.1.1.1 Some Tips for Starting
In Schedule Manager, you can display the Notes on Use. These offer valuable assistance for inexperienced
users.
 Note
You cannot drag and drop to the calendar reports that do not have variants stored in the task list.
You can start the report from the context menu.
Details on this entry can be found under Details. If you want to enter a variant, switch the mode by choosing
Change Task List. You can then edit the variants for the report.
9.1.1.2 Procedure for Running a Job in Schedule Manager
Use
If a job is available in Schedule Manager, you can start it manually or schedule processing in the system for a
certain date and time or even periodically.

520 PUBLIC Background Processing
Procedure
Proceed as follows:
1. Start Schedule Manager under FS-RI: Reinsurance Periodic Processing Schedule Manager:
Scheduler . The Schedule Manager: Schedule Tasks for Task List <Name of Task List> screen appears.
2. From here, you can run or schedule the respective jobs.
3. To call a job directly, select the job in the task list and choose Execute Task in the application toolbar. For
instructions on how to schedule a job, choose the Notes on Use button (you can switch off the application
help by choosing User Notes Off). Follow the instructions.
Result
You have started the background job or have scheduled a background job.
9.1.2 Schedules
No schedules are provided since the FS-RI system does not contain any periodic, sequential tasks. For more
information, see the relevant SAP documentation.
9.1.3 Monitor
The reports provided by the FS-RI system communicate with the Schedule Manager monitor.
Once the job has run, the user is informed of the progress of the tasks.
9.1.4 Log for Background Jobs
Use
When you run a background job, the system creates a log that you can use for information about the program
run and for troubleshooting.
Activities
● The list shown on the screen can be used to display the log right after the job has been run.

● The log can also be accessed using the transaction Analyze FS-RI Application Log (/MSG/R_SLG1) and can
be analyzed here.
● Use the transaction Application Log:Delete Logs (SLG2) to delete the log. Note that logs are not deleted
automatically.
Use
background jobs.
Features

● Process Treaty Calculation Rules (accounting function: TCR)
● Create Opening Reserves in Risk Manager and Execute Reserve Carryforward (Opening and Closing
Reserves) in Basic System (accounting function: OPRSV)
functions.
Special Features

Manager functions.
Transfer Group
When accounts are transferred as part of mergers and acquisitions [page 307] they are summarized according
to the selection period.
If the selection period is Year to Date and Inception to Date, flexible summarization is used in the treaty
calculation rule.
If the selection period is Incremental, the account is not summarized.
Activities
 Note
this purpose.

If a summarization variant has been set to inactive in Customizing, you can no longer assign it to a treaty. This
variant continues to apply to the treaties in which it has been entered.
9.2 FS-RI Background Jobs
The functions described in this section support the following:
● General functions
● Functions for period-end closing
● Adjustment functions
● Mergers and acquisitions
● Special functions
● FS-RI interface
9.2.1 General Functions
The background jobs described in this section support the following:
● Management of single risks

● Loss processing
● Account processing
● Retrocession
9.2.1.1 Management of Single Risks
The RM Combined Background Job (/MSG/H_P_BAT_COMPLETE) is provided for the management of single
risks.

9.2.1.1.1 Risk Manager Combined Background Job
Use
You can use the RM Combined Background Job background job (/MSG/H_P_BAT_COMPLETE) to execute the
following functions in Risk Manager:
● Liability Aggregation [page 75]

● Cession Group Creation [page 93]
● Cession Calculation [page 95]
● Confirm Status
Integration
You can also execute these functions online for specific policies, participations, cession groups or accumulation
groups.
Prerequisites
You must be authorized to run the job. This also applies for the online functions. You must also adjust the
authorization for the background authorization object YRVB_BATCH.
Features
This background job executes the above transactions in a process chain.
You can restrict the number of process steps. You select one of the radio buttons to specify the process step up
to which you want the system to process the object.
Activities
1. Fill the Company Code field under Business Settings.

2. Under Effect of Company Code Selection select Partial Coverage or Full Coverage.
 Note
The subfunctions Cession Group Creation and Cession Calculation process only participations and
cession groups that belong to the specified central company code or one of its local company codes.
For more information, see Chain of Company Codes [page 101].

3. You also specify the extent to which you want this background job to process in-force business:
○ Process Entire In-Force Business
○ Process Using Database Table
○ Process from Interface
○ Process Using Selection
4. You can select an option under Process Configuration and specify the step up to which you want the system
to process objects:
○ Up To Liability Aggregation
○ Up To Cession Group Creation
○ Up To Cession Calculation
○ Complete Process Chain
5. Start the background job using Schedule Manager.
6. Check the list of results.
9.2.1.2 Loss Processing
This section contains the following background jobs:
● Generate Loss Event

● FGU Distribution “FCFS” (Risk Manager)
● FGU Recalculation Process (Risk Manager)
● FGU Distribution “FCFS” (Basic System)
● FGU Recalculation Process (Basic System)
● FGU “Distribution Pro Rata Capita” (Parallel)
● Pro Rata Capita Distribution by Structural Characteristics
● Pro Rata Capita Distribution by Structural Characteristics (Parallel)
● Loss Recalculation
9.2.1.2.1 Generate Loss Event
Use
The technical name of the background job is /MSG/R_U_BATCH_EREIG_GEN.
You use this function when you want to assign single losses to loss events according to criteria determined by
you.
Prerequisites
● You have defined the maximum duration of a loss event in the “Loss Event Duration” field on the “NP
Liability” tab page at section level in the treaty.

● You have defined an employee responsible for large losses in the header data for the treaty.
Features
Once you have entered a search period and search criteria in the entry screen for the report and started the
report, the system performs the following:
1. The system processes the first loss whose occurrence date is at least the same as the start date of the
specified search period.
2. The system checks whether there are other losses whose start and end time falls within the loss event
duration according to the start time of the first loss, and that match the criteria for compliance for the first
loss.
3. If the system finds such losses it generates a loss event and assigns the first loss found, and any
subsequent losses found, to this event.
4. The system then processes the next loss that has not yet been assigned and proceeds in the same way.
5. After all relevant losses have been processed, in the application log the system creates a list of the losses
processed and the loss events generated.
9.2.1.2.2 FGU Distribution "FCFS" (Risk Manager)
Use
The technical name of this background job is /MSG/H_FI_P_BATCH_FGU_SPLIT.
In the FS-RI system you can distribute loss amounts for a cedent to the assigned Risk Manager participations
"from ground up" (FGU). You must distribute the amounts using the (proportional or non-proportional) liability
data defined in the participations.
This function is referred to as an FGU account. A similar function exists in Basic System.
Integration
You can distribute FGU accounts in the loss dialog. For more information, see Distribution of FGU Accounts
[page 642].
There is also a background job for reversing generated accounts and redistributing the underlying FGU
accounts. For more information, see FGU Recalculation Process [page 528].
Prerequisites
The system administrator has assigned you the authorization to execute FGU background jobs.

Features
You can distribute FGU accounts to the assigned participations at the cedent level of a loss. However, you
cannot create postings for the assigned original policies or policy sections directly, or distribute accounts
automatically to these entities (market loss distribution).
The program only supports one-level FGU distribution. This means that when you distribute an FGU account,
the amounts are only distributed to the participations directly assigned to the loss. Further distribution to
participations assigned via groups is not supported by the FGU account function. Instead, you have to use the
Transfer to Reinsurance/Retrocession function in the Risk Manager account (Re/Retrocession pushbutton) or
run the Transfer Accounts to Retrocession background job.
The processing of reference ranks is not supported. The participations assigned to a loss are each processed
with the reference rank 0, independently of one another. The system assigns an attribute to all resulting
accounts to indicate that they were generated by FGU distribution.
Activities
1. Enter the values for the required fields (minimum).

2. Start the background job.
4. Depending on the specified target status, you can then perform further activities, such as splitting,
calculating, and releasing the account.
9.2.1.2.3 FGU Recalculation Process
Use
The technical name of the background job is /MSG/R_A_BATCH_NP_CHANGE.
You run this background job if the data for a non-proportional treaty or for a loss (loss event, loss reference) has
changed, affecting a non-proportional account. The background job determines what changes have been made
and adjusts the non-proportional account.
You can choose whether the background job processes all accounts for a specific treaty or for a specific loss.
Constraints
This background job does not include changes to the signed line.
This background job does not include postings from Risk Manager.
To recalculate treaty calculation rules, use the background job Reset/Reprocess Treaty Calculation Rules (Basic
System).

Features
Calculable Changes
This background job performs recalculations:
● For all changes to a single non-proportional treaty (if applied to a treaty)

● For all changes to the attributes of a loss (if applied to a loss)
● When calculating a manual posting for a treaty share at the treaty level of the loss
Non-Calculable Changes
The background job does not support the following changes. If you use the background job to calculate these
changes, the system either produces an incorrect result or no result.
● Reference rank treaties that refer to the changed treaty

● Changes to Risk Manager polices that have been assigned to a loss
● Changes to a treaty assigned to the treaty calculation rules
Parallel Processing
Error Tolerance
background job is not interrupted. Exception: If the background job needs the results from the treaty
containing errors to calculate the next treaty, the system terminates processing after an error occurs.
Activities
If you have made changes to the treaty, enter the data for the treaty and company code on the initial screen. If
you have made changes to the loss, enter the data for the loss and company code on the initial screen.
The system performs the following activities.
Treaty Changes
1. The system selects all the postings for the section and period of the treaty that has been changed. Note:
These are all net and gross postings.
2. The system redistributes the gross postings to the assigned treaty sections.
3. These are combined with the previous net postings that have already been read. If necessary, the system
creates adjustment postings.
4. If postings are not covered, the system lists in the log which accounts are not covered and why.
Procedure If Attributes Are Deleted
If attributes are deleted, we recommend you:
1. Remove the structural characteristics.

2. Run the background job but do not release the accounts; the system creates reverse postings as a result of
the deletion.

3. Undo the changes made to the treaty.
4. Release the accounts generated while the background job is running.
5. Deactivate the “Simulation” checkbox and run the background job. The system deletes postings that are
not covered and not released, and reverses postings that are not covered but are released.
 Note
The system does not create and release postings that should be released with attributes no longer
covered. This is not a generally permitted procedure in the FS-RI system and is not supported by the
background job for recalculation. If the treaty to be recalculated has been assigned losses with
reference rank treaties that refer to this treaty, these reference rank treaties are not included in the
calculation.
Changes to Attributes for a Loss
You must ensure that none of the treaties assigned to the loss have themselves been changed.
During the recalculation process for a loss, the system performs calculations for all treaty sections assigned to
the loss in the same way as for treaties. The system can recalculate non-proportional treaties only and does not
include quota share treaties. If the treaty to be recalculated has been assigned losses with reference rank
treaties that refer to this treaty, these reference rank treaties are not included in the calculation.
If layer treaties (true non-proportional treaties) have been defined on top of quota share treaties, or vice versa,
the system does not currently support the calculation process for the quota share treaties. However, the non-
proportional treaties are recalculated, even if they are reference rank treaties.
 Note
The set of attributes in the non-proportional rank treaty must be subset of the attributes in the non-
proportional reference rank treaty. The set of attributes in the rank treaty must not be a superset of the
attributes in the reference treaty. This not only applies to the recalculation function, but to non-proportional
accounts in general. The same restriction also applies to reference rank chains.
9.2.1.3 Account Processing
● Split (Risk Manager)

● Transfer from Risk Manager to Basic System
● Split, Calculate, Release Parallel to Treaty (Basic System)
● Split, Calculate, Release Parallel to Account (Basic System)
● Split, Calculate, Release (Basic System)

9.2.1.4 Retrocession
● Transfer to Retrocession (Risk Manager)

● Adjust Retrocession After Changing Loss (Risk Manager)
● Adjust Retro After Changing Ceded Treaty (Risk Manager)
● Transfer to Retrocession (Basic System)
● Retrocession Adjustment (Basic System)
● Process Treaty Calculation Rules (Basic System)
● Process Treaty Calculation Rules (Parallel) (Basic System)
● Reset/Reprocess Treaty Calculation Rules (Basic System)
9.2.1.4.1 Process Treaty Calculation Rules (Basic System)
Context
The technical name of the background job is /MSG/R_ABR_VTGRECHENREGELN.
You use this background job to apply a defined treaty calculation rule to the transfer of posting data.
Flexible Summarization
You can use the rules of flexible summarization to restrict the number of accounts generated by this
background job.
Procedure
Run the background job with the required data. Here "Accounting Year" (accounting year of cedent) and
"Period" (accounting period of cedent) both refer to the target account. You can start the background job
manually or schedule this in Schedule Manager.
 Note
You can set the actual/estimate indicator for the target account. If you do not make an entry here, the
system copies the actual/estimate indicators from the inward to the retrocession accounts.
Check the validity of the calculation time
The program reads a log table to determine the time stamp (time and date) of the last run date for the
treaty calculation rule for the company code provided. It compares the last target time period with the
current target accounting period (which must be after or the same as the previous one).

2. Select the posting data to be calculated
In the case of source rules, the system finds the source accounts for which posting data is to be calculated.
These are accounts that belong to sections in:
○ Treaties with the same treaty category of the rule (if entered) or in assumed treaties (if treaty category
is not entered)
○ Treaties with the same nature of treaty of the rule (if entered)
○ The treaty stored in the rule (if entered)
○ The section stored in the rule (if entered)
The following also applies to the account:

○ The end of the accounting period must be before or the same as the end of accounting period of the
target accounting period
○ The business type in the target section must be the same as that in the rule
○ The financial year must be after or the same as the smallest open financial year (of the company code)
○ If the account was released before or since the background job was last run, it must belong to a period
(end date of accounting period) that has no yet been calculated or was generated by the current
background job
This is because when you run the background job for the first time, the system creates an entry in a log
table with the selection parameters and the time stamp of the run. If you run the background job again at a
later date with the same parameters, the system finds all the accounts that have been released since the
last time stamp. These accounts are then included in the target treaty.
In the case of these accounts, the system considers postings that:

○ Belong to a class of business of the target section
○ Are assigned to an area that is covered by the target section
○ Belong to a line of business of the target section
○ Fall within the periods of the target section in accordance with the mode
○ Use an entry code from the result-independent conditions for the portfolio rule accounting time
"Treaty Calculation Rule". In this case, the condition categories "Filter" and "Transfer" are allowed.
 Note
In addition to these conditions for accounts and postings, the criteria defined in the plus or minus rule
also apply.
3. Apply the treaty calculation rules
The system applies the result-independent conditions entered in the target section with the portfolio rule
accounting time "Treaty Calculation Rule" in the order of their rank.
If a global condition with the category "TCR" has been entered in the target rank of the treaty calculation
rule, this condition is used instead of the result-independent conditions in the treaty.
In both cases, the system proceeds as follows:

1. It uses the financial year and accounting period to determine the FI posting date.
2. In each treaty calculation rule, the system calculates the ranks with the usage type "Equal To" (in
ascending order). It includes the lower ranks with the usage type "Plus" or "Minus". For each entry with
the usage type "Equal To", the system considers all periods for which posting is allowed. If you enter
only one treaty in the entry, the system considers all sections; otherwise, it considers the specified
section only. The system calculates any result-independent conditions entered in the target section

with the portfolio rule accounting time "Treaty Calculation Rule". In this case, you can enter only the
condition categories "Filter" and "Transfer". For more information about treaty calculation rules with
several "Equal To" ranks, see "Interim Results in Treaty Calculation Rules".
3. The system multiplies the result by the plus/minus sign and percentage of the treaty calculation rule
and posts this to the main area, business type, class of business, and line of business of the target
section.
This is because when you call the background job, the system finds the processing rule for the first target
treaty in the treaty calculation rule or creates an internal description of the selection criteria relevant for
the target treaty. It then uses these criteria to find the corresponding data for each plus or minus rank. To
do this, the system starts a separate reading operation for each plus or minus rank.
 Note
You have a stop loss treaty. At year-end you want to find out whether the liability is covered by this treaty. To
do this, use the treaty calculation rules to transfer the premium and loss payments from the covered
treaties to the stop loss treaty as statistical postings.
In this example, the covered treaties are the source treaties and the stop loss treaty is the target treaty.
You create the rule as follows:
1. Choose Reinsurance Basic System RI Programs Create Treaty Calculation Rules or Change
Treaty Calculation Rules.
2. Enter the source treaties as "Plus" ranks, and the target treaty as an "Equal To" rank. You can enter the
treaties explicitly in the "Plus" ranks or enter these as a set of treaties that meet the specified criteria.
In this simple example, the system transfers all accounts in the source treaty to the target treaty. When you
call the background job, the system includes all accounts in the source treaty released since the last
background job was run.
Start the background job in Schedule Manager.
The background job determines which postings are affected and transfers these to the target treaty in
summarized form.
9.2.2 Functions for Period-End Closing
The background jobs described in this section support the following:
● Treaty management
● Treaty conditions
● Forecast and estimation
● Premium schedule
● Reserves carried forward

9.2.2.1 Treaty Management
The background job Copy Treaty Periods (/MSG/R_KOPIEREN_BATCH) is provided in the area of “treaty
management”.
9.2.2.1.1 Copy Periods
Use
The technical name of the background job is /MSG/R_KOPIEREN_BATCH.
You use this background job to copy treaty periods. You may need to do this if business is extended at the end
of the year.
Features
You use this function to copy the periods within a treaty in a background job. After you enter the copy criteria,
the system copies the period to all treaties that contain the source period. It then displays a log.
The status of the new period is set as follows.
If all parts are copied exactly Source and target have same status
If source is cancelled Status of highest status (COPY)
If parts are not copied (installment schedule, for example) Status of highest status (COPY)
For more information about copying periods, see Copying Treaty Periods [page 302].
Activities
Required Data
Treaty Category and Nature of Treaty: Select the treaty category to be copied to
Status: Periods with statuses that are canceled and do not allow posting are not copied
From Period: Source period
To Period: Target period (this may not yet exist)
Background Job
After you fill all the required entry fields, the system selects the treaties that have not been deleted and have
the correct treaty category and nature of treaty. It copies all the data in the existing source period to the target

period. The installment schedule is not copied because the source and target period are different and this
would mean that incorrect due dates are displayed for advance payments.
When the background job has finished, the system displays a log. This log contains the selection parameters.
The treaty number and a report are also displayed for every treaty. The report contains error or success
messages, for example:
Example
● No data found for treaty category and nature of treaty

● Target period already exists in this treaty
● Status of the treaty is canceled and does not allow posting
● Selected period does not exist
● You are not authorized to change this treaty
● Status xxx successfully copied to status xxx
9.2.2.2 Treaty Conditions
The following background jobs are provided in the area of treaty management:
● Calculate Unearned Premiums (Risk Manager)

● Calculate Unearned Premiums (Basic System)
● Recalculate Conditions (Risk Manager)
● Adjust Periods (Parallel) (Basic System)
● Adjust Periods (Basic System)
● Calculate Result-Dependent Conditions (Basic System)
● Calculate Global Conditions (Parallel) (Basic System)
● Calculate Global Conditions (Basic System)
9.2.2.2.1 Adjust Periods (Basic System)
Use
The technical name of the background job is /MSG/R_A_B_PERIOD_ADJUST.
You use this background job to calculate and post the result-independent conditions and reinstatement
premiums (or to recalculate these after changes have been made). You can also use this job to value reserves.

Features
Scope of Processing
The background job processes only Basic System accounts that have the status Released and contain a share.
If you set the Release Accounts checkbox, the system also processes accounts with the status For Batch
Release and To Be Split and Released by Batch.
In these accounts the system processes only subpostings and original postings without subpostings that are
not reversed.
You can use the various parameters on the selection screen for the background job to restrict the processed
treaties, accounts, and conditions to be calculated.
 Tip
We recommend you use these parameters to reduce the runtime of the background job.
Calculation Function
For more information about the calculation function, see “Calculating Accounts”.
Difference Postings/Reversal Postings/Actual Postings
To control whether the background job generates difference postings, reversal postings, or actual postings, you
set the Post Differences checkbox in external Customizing for Basic System under Default Values Edit
Defaults for Accounting (Calculation Fields) .
Summarization
The Summarize function improves system performance and reduces the number of adjustment postings. If
you set this checkbox, the system processes in an adjustment posting all the data posted in the target
accounting year if the end date of the accounting period is before or the same as the end date of the target
accounting period.
Identification of Generated Accounts
Each account is assigned an origin indicator, which references the source of the recalculated conditions. This
enables you to select and analyze these accounts specifically later on.
Simulation Mode
In simulation mode, the system creates preliminary accounts. If you execute the job a second time, the system
first deletes all existing preliminary accounts.
Parallel Processing
Error Tolerance

Activities
1. Enter the required data. (here the accounting year is the accounting year being closed). The accounting
period is used only to select the accounts to be processed. This entry does not effect the target accounting
period of the generated accounts. You can make other entries to restrict the sections, accounts, and
conditions to be processed.
2. If you have set the Release Pending Accounts checkbox, the system searches all the accounts for the
selected treaty sections and periods, splits these and releases them (if this has not already been done).
3. The system uses the criteria entered by the user to select the accounts to be processed. The following
sequence applies:
1. Treaty sections and treaty periods
2. Conditions
3. Accounts
4. The system summarizes the accounts to be adjusted.
5. The system calculates the reinstatement premiums, if you have set this checkbox.
6. The system calculates the result-independent conditions of the categories and entry codes selected. The
result-independent conditions are calculated in the order of their rank; deposit rules are always calculated
after other conditions.
7. The system calculates the postings for the valuation of reserves, if you have set this checkbox.
8. The system compares the results of its calculations with any earlier postings from the conditions and
creates any necessary adjustment postings (at share level).
9. The system processes the adjustment postings in the steps entered in the “Scope of Processing” field.
Related Information
Calculating Accounts [page 634]
9.2.2.2.2 Calculate Global Conditions (Basic System)
Use
You use this program to calculate and post the conditions from the global conditions (see “Global Condition”).
Prerequisites
The background job processes only:
● Treaties that meet the selection criteria for the processed global conditions
● Treaty sections in which the Apply Global Conditions checkbox has been selected
● Basic System accounts with the status Released

● Postings that meet the selection criteria in the global conditions
● Global conditions with the category STD
In addition, several parameters on the selection screen for the background job allow you to restrict the
treaties being processed. We recommend you use these parameters to reduce the runtime of the
background job.
Features
Two versions of the Calculate Global Conditions background job are available. Both offer the same functional
features but have different processing methods.
The technical names of the background jobs are:
● /MSG/R_A_BATCH_GKV_PP (parallel processing)

● /MSG/R_A_BATCH_GKV_SER (serial processing)
Calculation Function
For more information about the calculation function, see Calculating Accounts [page 359].
Difference Postings/Reversal Postings/Actual Postings
To control whether the background job generates difference postings, reversal postings, or actual postings, you
select the Post Differences checkbox in Customizing for Basic System under Default Values Edit Defaults
for Accounting (Calculation Fields) .
Each account is assigned an origin indicator to make the selection and evaluation of the generated accounts
easier. The background job assigns two origin indicators:
● Portfolio Entry with Clearing for account from the PTFEC calculation [page 249]
● Calculate Global Conditions for all other accounts generated using the background job
Simulation Mode
In simulation mode, the system creates preliminary accounts. If you execute the job a second time, the system
first deletes the preliminary accounts for the selected treaties from previously calculated global conditions.
Parallel Processing
If you have a large amount of data to process, the parallel processing version of the background job offers
better system performance.
However, while the system is processing the relevant objects (in a series and in parallel), neither background
job locks the other objects contained in the same table. This means you can run several background jobs at the
same time and work with objects not being processed while the background job is running.
Error Tolerance
If one of the objects being processed by the background job causes an error, the system records this error in
the log; the background job is not interrupted.

Activities
1. Enter the required data. The accounting period (Key Date From – Key Date To) is used to select the
accounts to be processed. The other entries determine the treaties to be processed and the global
conditions to be calculated.
2. The background job uses the criteria entered by the user to select the accounts to be processed. The
following sequence applies:
1. It uses the selection criteria entered to identify any treaty sections to be calculated.
2. It checks in which of these treaty sections the Apply Global Conditions checkbox has been set.
3. It filters these sections based on the selection criteria in the global conditions.
4. It selects the accounts and postings for these sections.
5. It filters these postings based on the selection criteria in the global conditions.
3. The background job summarizes the accounts to be adjusted.
4. The background job calculates the result-independent conditions using the global conditions. The
conditions are calculated in the order of their rank.
5. The background job compares the results of its calculations with any earlier postings from the conditions
and creates any necessary adjustment postings at share level.
6. The system processes the adjustment postings in the steps entered in the “Scope of Processing” field.
Example
Unearned Premiums in Occurrence Year Business with Global Conditions [page 253]
Fire Department Charges with Global Conditions [page 255]
Related Information
Global Condition [page 251]
9.2.2.2.3 Calculate Result-Dependent Conditions (Basic

System)
Use
The technical name of the background job is /MSG/R_ABR_VABHKOND.
You use this background job to calculate the results of result-dependent conditions and create the
corresponding postings.

Integration
We recommend you schedule the background job for processing result-dependent conditions in Schedule
Manager so that it is run at a certain time after accounts for a treaty have been released, for example after final
accounts have been generated for each treaty period.
Prerequisites
This background job calculates conditions using only those accounts, and postings in these accounts, which
meet the following prerequisites.
Included Accounts
● The account belongs to the treaty and section specified in the condition.
● The account belongs to the share currently calculated. If a share is entered in the condition, the condition
is only calculated for this share. Otherwise, it is calculated for each reinsurer share individually (except for
the owner company's shares, in the case of ceded treaties).
● The account has the status Released or For Batch Release.
● The account is not reversed.
Postings in the Accounts
The entry code for the posting is evaluated in the condition (calculation base 1, calculation base 2, and so on).
Year Basis for Condition: Accounting Year
● The posting lies in a period, the start date of which is before the specified accounting year.
● The start of the accounting period for the account falls within the period.
Year Basis for Condition: Occurrence Year
● The adjustment period or the adjustment period after withdrawal has not expired and the calculation
waiting period is over.
● The occurrence date lies within the period.
Year Basis for Condition: Underwriting Year
● The adjustment period or the adjustment period after withdrawal has not expired and the calculation
waiting period is over.
● The underwriting date lies within the period.
Features
The result of result-dependent conditions is always a posting, which is created according to specific criteria in
the treaty. The system calculates the resulting posting from a condition with a fixed amount (for example, a no-
claims bonus), a fixed percentage (for example, a profit commission), or a scaled percentage (for example, a
commission, the percentage amount of which depends on the loss ratio). You can stipulate whether each
condition is calculated.
Result: Fixed Amount

If the result of the condition is a fixed amount, the system checks whether the specified criteria is met and, if
so, posts the amount.
Result: Fixed Percentage
If the result of the condition is a fixed percentage, the system calculates the amount to be posted using the
percentage and percentage calculation base.
Result: Scaled Amount/Percentage
If the result of the condition is a scaled amount or percentage, the system proceeds as follows:
1. It determines the calculated result. This is either an amount or a percentage. The amount can be the result
of calculation base 1 or the result of linking calculation base 1 and calculation base 2. The percentage is
always the result of both calculation bases, linked by the operator "/".
2. It determines the applicable value or percentage produced by the calculated result. Results that do not
match a calculated result defined in the scale can be interpreted in four ways:
○ Layered
○ Mean value
○ Round up
○ Round down
3. It posts the calculated result after deducting an existing posting value for the target entry code.
Block
If you have entered a block in the condition, the system calculates the condition using all the postings that
occur over the duration of the block and meet all prerequisites.
For more information about result-dependent conditions with blocks, see Sliding Scale Commission in Three-
Period Block (Based on Loss Ratio) [page 226].
Profit or Loss Carryforward
If you have entered a profit or loss carryforward in the condition and the relevant criteria are met, the system
processes the carryforward as described in the example in Profit Commission with Loss Carryforward [page
223].
Compensation Rules
If you have entered a compensation rule, the system processes this as described in Compensation Rule [page
229].
Parallel Processing
Error Tolerance

Activities
Once you have entered the treaties and date for which the conditions are to be calculated and have started the
background job, the system performs the follows actions. You can also schedule the background job for a
specific time, using Schedule Manager.
1. It checks the entries and reads the conditions.

2. It sorts the conditions according to their rank to ensure that these are calculated in the correct sequence.
The system also considers funds data, as described in Funds Retained and Release of Funds [page 261]
(under "Integration").
3. It determines the postings to be included in the calculation (as described under "Prerequisites").
4. It translates the postings into the local currency and calculates the calculation bases. In doing so, it
subtracts the management expenses from the calculation base for loss adjustment expenses (calculation
base 1 or 2).
5. When processing blocks, it also evaluates postings from treaty periods covered by the block.
6. If the year basis for the condition is “Accounting Year”, also calculates the ceded amounts from earlier
periods provided you have entered a suitable treaty type in the condition.
7. It considers any compensation rules.
8. It calculates the result for the condition depending on the operator. This result can be an amount (if
operator is +, -, and x) or a percentage (if the operator is /). In the case of a percentage, the absolute
percentage is always used (without plus/minus sign).
9. If you have entered criteria, the system checks to ensure the result meets these. If no condition is entered,
it is treated as always fulfilled.
9.2.2.3 Forecast and Estimation
The following background jobs are provided for the forecast and estimation:
● Forecast and Estimation (Parallel) (Basic System)

● Forecast and Estimation (Basic System)
9.2.2.3.1 Distribution of Values to Periods and Sections in

the Treaty
In the header data for the forecast and estimation rule, you enter the section and periods of the treaty
(occurrence, underwriting, and accounting period) for which the forecast or estimation values are to be
calculated.
You do not need to restrict the validity to one section and to specific periods but you can also enter values for
several sections or for entire intervals that apply across treaty periods. If you want to enter a rule for more than
one section, leave the “Section” field empty in the header data. If you want to create a rule for longer time
intervals, enter the start and end dates.
If you cannot specify the rule in enough detail in this way, you must distribute the estimated values to the lower
levels.

Distribution to Underwriting Years
You use the “Distribution Details” tab page on the level below to distribute values to underwriting years. On this
tab page you can enter the percentage of the value calculated by the forecast and estimation rule that is
distributed to different underwriting years.
Distribution to Sections
You can distribute each of the underwriting year periods entered to different sections. To do this, double-click
the period to branch one level lower.
9.2.2.4 Premium Schedule
The functions described in this section support you during period-end closing in the area of premium
schedules:
● Calculation of premium schedule (Risk Manager)

● Calculation of advance premium (Basic System)
● Adjustment of non-proportional (NP) premiums
9.2.2.4.1 Adjust Non-Proportional (NP) Premiums
Use
The technical name of the background job is /MSG/R_A_BATCH_NP_PREM_ADJUST.
You use this background job to adjust the premiums for non-proportional obligatory treaties.
Prerequisites
This job processes non-proportional obligatory treaties and their sections. You must have entered a fixed
premium rate or a minimum or maximum premium rate, as well as final subject premium (GNPI), as a
calculation base or amount on the “NP Premium” tab page. The job analyzes only those treaty periods that
have a status that allows posting.
It does not process treaty sections for which a fixed premium or a sliding scale has been agreed.
You can adjust NP premiums only if have entered a target entry code for adjusting NP premiums in
Customizing.

Features
Adjusting the Premiums
When you start the background job, the system reads the NP premium data of the treaty for each treaty period
and creates the necessary premium adjustments. For more information, see points 2 to 5 under “Activities”.
If you start the background job as an actual run (without simulation and the actual/estimate indicator is set to
“Actual” for the target accounts), the system updates the final premium in the treaty after the job has run
without errors. For more information, see point 6 under “Activities”.
Parallel Processing
The job adjusts the premiums for the treaties in question in parallel processes. You can specify the package
size. The treaty is the smallest unit that can be processed by a process.
Error Tolerance
If one of the objects being processed by the background job causes a non-critical error, the system records the
error in the log; the background job is not interrupted.
Logging
If you want to view the individual calculation steps of the “Adjust NP Premiums” background job, set the
“Detailed Log” checkbox.
Scheduling
You can start the background job manually or schedule this in Schedule Manager.
Activities
1. Run Background Job
1.1 Restrict Treaties
You can use the Parameters to Restrict Processed Treaties to restrict the adjustment of premiums to specific
treaties, treaty sections, and treaty periods. Since premiums only have to be adjusted at the end of a treaty
period, you can restrict treaty periods by their end date.
You use the FI posting date and the accounting period to further restrict the treaty periods being adjusted: The
system then adjusts only those treaty periods whose start date is before or the same as the specified
parameters.
1.2 Restrict Accounts
If you enter an FI posting date and an accounting period, you also restrict the selection period for the accounts
relevant for calculating the GNPI. You can also use the Source of Actl/Estimate Comb. field to restrict the
adjustment of premiums to specific types of accounts.
1.3 Parameters to Be Transferred to the Accounts for Adjusted Premiums
The FI Posting Date, Accounting Period, and Actl/Est. Ind. Generated Acct parameters are copied to the
accounts that are created for the adjusted premiums. For more information, see point 5.
2. Calculation Level

Premiums are always adjusted separately for different reinsurer shares. This means that premiums are not
calculated for all reinsurer shares and then distributed to the individual shares.
3. Calculation of the Final Subject Premium for a Reinsurer Share
If you have entered a calculation base for the GNPI in the NP premium data, the system calculates the final
subject premium for a reinsurer share by evaluating the data posted for this share.
If you have entered the final subject premium instead as an amount in the NP premium data, the system
multiplies this amount by the reinsurer's effective share.
4. Calculation of the Final Premium for a Reinsurer Share
The system calculates the final premium based on the premium percentage:
● Fixed premium percentage

If you have agreed a fixed premium percentage, the premium is the product of the fixed premium
percentage and the final subject premium. If this premium is smaller than any additionally agreed
minimum premium the system applies the minimum premium.
● Variable premium percentage
If you have agreed a variable premium percentage, the system first calculates the applicable percentage.
To do this, it calculates the loss quota (by applying the calculation bases entered in the NP premium data
for GNPI and losses incurred). It adds a loading factor entered in the treaty to the loss quota.
If the loss quota plus the loading factor is smaller than the minimum percentage, the minimum premium
percentage is used as the premium percentage. If it is larger than the maximum premium percentage, the
maximum premium percentage is used as the applicable premium percentage. Otherwise, the applicable
premium percentage is the loss quota plus the loading factor.
The premium is calculated as the product of the applicable percentage and the final subject premium.
If this premium is smaller than any additionally agreed minimum premium the system applies the
minimum premium.
You can view the interim results of the calculation steps in the detailed log.
5. Creation of the Account for Adjusted Premiums
The system compares the final premium (expected premium) with the premium that has already been posted
(actual premium; corresponds to the sum of the advance premiums and the adjustment premiums).
An adjustment is made if there is a difference between the actual premium and the expected premium. The
actual premium is cleared and the expected premium is posted. No adjustment is made if there is no difference
or if the expected premium is zero.
If there is an adjustment, the FI posting date, the accounting date, and the actual/estimate indicator are copied
to the corresponding accounts from the start parameters for the background job, along with an meaningful
name for the accounts.
Each account is assigned an origin indicator, which references the source of the premium adjustment. You can
then select and evaluate these accounts separately.
6. Update Treaty
When you adjust the premiums in a final run (meaning that this is not a simulation run and the actual/estimate
indicator is set to “Actual”), the system adjusts the final subject premium (GNPI) and the final premium in the
treaty.
This depends on the existence of reinsurer-specific premium data:
● There is no reinsurer-specific premium data

The system updates the final premium on the “NP Premium” tab page in the treaty. It also updates the final
subject premium if a calculation base for a final subject premium is used for the calculation.
● There is reinsurer-specific premium data
The system creates an entry for all reinsurer shares that do not yet have an entry under NP Premium Data
on the NP Premium data tab page. When it does this, it copies the premium percentages from the Premium
Data area and scales any agreed minimum premium down to the reinsurer share based on the effective
share.
The system updates the calculation result for the final premium in the Final Premium column.
The Final Premium field under Premium Data is deleted. If the subject premium is defined in a calculation
base for a final subject premium, the Adjusted Subject Premium field is also deleted.
9.2.2.5 Reserves Carried Forward
The background jobs described in this section support you during period-end closing in the area of reserves
carried forward:
● Carry Reserves Forward to Target Year (Risk Manager)

● Carry Reserves Forward to Target Year (Parallel) (Basic System)
● Carry Reserves Forward to Target Year (Basic System)
● Carry Reserves Forward for Key Date (Risk Manager)
● Carry Reserves Forward for Key Date (Parallel) (Basic System)
● Carry Reserves Forward for Key Date (Basic System)
9.2.2.5.1 Carry Reserves Forward to Target Year
Use
The technical name of the background job is /MSG/R_A_BATCH_CARRY_FORWARD.
You use this background job to carry forward reserves from a source year to a target year.
Features
To process the reserve postings, the system creates totals for all the reserve postings whose accounts match
the following criteria in the original account (the account from which the reserve postings were called):
● Treaty
● Section
● Area
● Business type
● Original and account currency
● Share

Further subdivision takes place according to:
● Entry code
● Occurrence year
● Loss
● Recipient
● Broker
● Payment partner
● Global accounting unit
● Local accounting unit
A total is formed for each.
Postings that are created using an entry code relevant for financial accounting are selected according to the
financial year entered in the corresponding account.
Postings with an entry code assigned to the accounting year view are read according to the accounting year
entered in the corresponding account. The system always uses the year prior to the relevant target year as the
value for comparison.
The system selects only those postings that have not yet been carried forward.
It selects only entry codes for which a carryforward is required. In the case of deferred entry codes, the
occurrence year is also increased for each carryforward.
You use a separate indicator to highlight a carryforward in the same code. To indicate that an opening reserve is
being carried forward, you must assign an entry code applicable to opening reserves.
You can use the rules of flexible summarization [page 174] to restrict the number of accounts generated by this
background job.
Activities
When you enter the company code and target year and start the background job, the system proceeds as
follows:
1. It processes a closing reserve that has not yet been carried forward.
2. It creates an opening and closing reserve account for the next accounting year for this closing reserve. It
sets the Created by Carryforward checkbox in the new accounts.
3. It updates the year data and checks whether the target year has been reached. If not, the system repeats
step two. In doing so, it makes the following distinction:
1. If reserves are assigned to the accounting year, the system increases the accounting year by one each
time (the financial year remains the same). Once the accounting year is the same as the target year,
the system closes this reserve carryforward.
2. If reserves are assigned to the financial year, the system increases both the accounting year and the
financial year by one each time. Once the financial year is the same as the target year, the system
closes this reserve carryforward.

It may be that as a result of step 3a and 3b the function splits the account and carries financial and
statistical reserves forward separately.
For more information about reserve postings, see Reserve Posting [page 354].
9.2.2.5.2 Carry Reserves Forward to Target Year (Risk

Manager)
Use
The technical name of the background job is /MSG/H_FI_P_BATCH_OP_RES.
You use this background job to carry reserves forward from a source year to a target year.
In this context, reserves are provisions for expected future insurance payments. These may be loss reserves for
claims that have not yet been settled or made, or premium reserves for the unearned part of premiums already
received (see Unearned Premium [page 246]).
Integration
The system executes this function automatically when you transfer an account to Basic System (if you have
made the corresponding Customizing setting). You can also execute the function as a background job.
This background job is related to the background job Create Closing Reserves.
The closing reserves must first be generated for the preceding year, and no opening reserves must yet exist for
the target year.
Features
The program processes each closing reserves that has not yet been carried forward.
For each closing reserve, it creates an opening reserve for the next financial year or accounting year (depending
on the setting).
You can use the rules of flexible summarization [page 174] to restrict the number of accounts generated by this
background job.

Activities
1. Start the background job directly or using Schedule Manager.

2. Enter the values for the required fields (minimum).
Parameters
● Company Code
● Treaty
● Treaty Category
● Target Year
● Summarize (Yes/No). If you select “Yes”, the system groups the target postings.
Result
The opening reserves have been generated and can be carried forward by the background jobs Create Closing
Reserves (for loss reserves) and Post PRT Unearned Premiums (for premium reserves).
9.2.3 Adjustment Functions

The functions described here offer you adjustment functions for changed cession rules or participation
behavior:
● Change cession rules

● Change participation behavior
9.2.3.1 Change Cession Rules

The functions described here offer you adjustment functions for changed cession rules:
● Risk Manager adjustment after changes in Basic System

● Combined background job for Risk Manager
9.2.3.1.1 Adjustment of FGU Distributions

It may be necessary to make an adjustment to FGU accounts for the following reasons:
● The original FGU account was not entered correctly, but has already been distributed.
● The original FGU account was entered correctly and has been distributed. However, the attributes relevant
for accounting were not correct in the loss or participation at the time of distribution.
This function relates to adjustments for the second reason. Technically, the adjustment involves reversing the
(incorrect) FGU distribution postings and re-running the FGU distribution for the correct participation data.
You cannot perform this adjustment online from the dialog. However, you can trigger it using the background
job FGU Adjustment Based on a Loss [page 528]. For more information, see the details for this function. The

system also adjusts FGU distributions as part of the retrocession adjustment, which you can run online from
Contract Manager or as a background job.
Note on reason 1: In this case, you must reverse the FGU account and then enter and distribute a new FGU
account.
For more information, see Reversal of FGU Accounts [page 645].
9.2.3.2 Change Participation Behavior
The functions described here offer you adjustment functions for changed participation behavior:
● Adjustment after changing signed line (Risk Manager)

● Adjustment after changing signed line (Basic System)
9.2.3.2.1 Adjustment After Changing Signed Line (Basic

System)
Use
The technical name of the background job is /MSG/R_A_BATCHJOB_SL_CORR.
You use this background job to adjust accounts after changes have been made to the signed line of a treaty.
Features
If the share in a reinsurance treaty (signed line) is changed retrospectively, the system logs the relevant data
(treaty, share, percentage change) in a table. When you run this background job, the system accesses this table
and creates the necessary adjustment postings for each entry.
Parallel Processing
Error Tolerance
background job is not interrupted. Exception: If no number is available for the next account, the system

Activities
1. Enter the required data (here the FI posting date is the posting date of the accounts to be adjusted).
2. The system creates the corresponding adjustment postings.
9.2.4 Mergers and Acquisitions
The function described in this section supports you when you transfer a portfolio.
9.2.4.1 Portfolio Transfer
The functions described in this section support you when you transfer a portfolio:
● Execute transfer
● Undo transfer
9.2.5 Special Functions
The system provides background jobs for the following functions:
● Check due date rules and execute actions

● Check compliance with premium payment warranty
● Analysis of account assignment between Risk Manager Non-Life and Basic System
● Enter statistics and work tables
● Enter Risk Manager histories
● Currency changeover
● Currency changeover
9.2.5.1 Check Due Date Rules and Execute Actions
Use
This report checks the conditions defined in Due Date Manager [page 336] with the trigger Report and, if
these conditions are met, executes the assigned actions.

Features
The system checks whether the date entered in a rule in Due Date Manager matches the current date and
whether the other conditions defined in this rule are met.
If all the conditions are met, the system executes the specified action. This action can be a user-defined report
or a class, the performance of which cannot be influenced by this report. This report only calls the action.
 Recommendation
We recommend you run this report once a day to safeguard the functional scope of Due Date Manager.
 Caution
If the system executes actions using a background job, you must perform a detailed check of the jobs
performed since these cannot be checked by the job log.
Activities
The system reads the rules for all the treaties in the specified company code with the trigger Report and
processes each individual rule according to the following schema:
● Calculate date
● Check date
● Check conditions (if entered)
● Execute action (if the checks are successful)
 Example
Rule definition with the trigger Report
Trigger Base Date Time Shift/Time Condition Action Category Action Name
Unit
Report End of financial -1 month Cedent = XYZ Report MyReport

year
When it runs the background job, the system checks this rule since it has the trigger Report.
The date on which the job is run is: end of financial year - 1 month.
The check is therefore successful only a month before the end of the financial year entered in the treaty
header.
If the result of the treaty-related check to determine whether the cedent is XYZ is also positive on this date,
the system runs the report MyReport.

9.2.5.2 Check Compliance with Premium Payment
Warranty
Use
The technical name of this background job is /MSG/H_FI_P_BATCH_PPW.
This background job checks participations for premium payments that are overdue or about to become due
and reminds you of any payments it finds.
Features
The background job analyzes any number of treaties and related participations in which your company is itself
the cedent or co-cedent, and checks if a premium payment is due immediately or in the near future. You define
the time frame to be analyzed when you start the background job.
For more information, see Premium Payment Warranty [page 112].
Constraints
The background job that checks the dates for the premium payment warranty only checks participations for
which you have actually defined installment schedules.
For further constraints, see Premium Payment Warranty [page 112].
Activities
You can start the background job manually or schedule it in Schedule Manager.
The company code and treaty that you enter determine which data is analyzed.
The time limit in days determines how many days before the premium payment warranty deadline the system
issues a warning.
9.2.5.3 Analysis of Account Assignment Between Risk

Manager Non-Life and Basic System
Use
The technical name of this background job is /MSG/H_FI_P_BATCH_ADJ_RM_BASIC.
You use this background job to identify Risk Manager Non-Life (RMN) accounts that are marked as Transferred
to Basic System but have not been assigned to a Basic System account or for which a Basic System account
does not exist.

Exceptions
The background job also identifies accounts that have purposefully not been assigned as incorrect accounts.
Some examples are:
● The Transfer Accounts to Basic System background job is being used and summarization has been
activated.
● Flexible summarization is used to transfer the account to Basic System and the function to create an
account assignment is deactivated.
The Account Transfer from RM checkbox in the treaty header data is relevant because the background job does
not analyze accounts for treaties in which the checkbox has not been set.
Parallel Processing
Activities
1. Run the background job with the required input parameters. In this case, the mandatory parameter FI
Posting Date refers to the FI posting date of the RM account.
2. The system checks your entries.
3. The system uses the criteria entered by the user to select the accounts to be processed.
4. The system checks whether an assignment exists for each account. If an assignment does not exist, the
system creates an error message.
5. The system checks whether the Basic System account for an assignment exists in the database. If the
account does not exist, the system creates an error message.
6. The system displays any error messages in the application log.
Parameters
● Company code (multiple selection)

● Treaty (multiple selection)
● FI posting date (multiple selection)
9.2.5.4 Enter Statistics and Work Tables
The functions described in this section support you when you enter statistics and work tables:
● Determination of counter readings in the CAP log

● Generation of statistics table WKLISTEC (Risk Manager)
● Filling of statistics tables WKLISTEC and WKDEPOT (Basic System)
● Filling of work table WKANTSCHAD
● Writing of off pre-euro currencies from fund work table

9.2.5.4.1 Create Work Table for Ledger Group
Use
The technical name of the background job is /MSG/R_A_FILL_LDGRP.
You use this background job to assign a ledger group [page 481] from FI Customizing to every combination of
company code and entry code.
You use this background job after you have entered the data relevant to ledger groups or after you have
changed the following data:
● Ledger groups in the FI table (create, change, delete)

● Entry codes in the entry code table (create, change, delete)
● Table of accounting principles assigned to entry codes (create, change, delete)
● Table of accounting principles assigned to company codes (create, change, delete)
Prerequisites
● You have assigned FS-CD as the current account system for the company code.
● You have set the Use Ledger Group checkbox for the company code in Customizing for Basic System under
Default ValuesEdit Defaults for Accounting .
● You have marked the entry code as FI relevant and as a non-cash entry code and have assigned it to an
accounting principle relevant for financial accounting in the current company code. You mark an entry
code as FI relevant by setting the Transfer to FI checkbox in Customizing for Basic System under
Accounting Entry Code Edit Entry Code Definitions .
● The company code and entry code have a common accounting principle that is assigned to a ledger.
● The system uses only active assignments between accounting principles and company codes to find the
ledger group.
● The periods entered in this work table do not overlap.
Features
The system creates an internal table. In this table, the valid ledger group is assigned to every combination of
company code and non-cash entry code for a specified period. The system uses the entries in the following
Customizing activities to find the correct ledger group:
● SAP Customizing Implementation Guide FS-RI Reinsurance Basic System Accounting

Accounting Principles Edit Accounting Principles
Accounting Principles Assign Accounting Principles to Entry Codes
Accounting Principles Assign Accounting Principles to Company Codes

● SAP Customizing Implementation Guide Financial Accounting (New) Financial Accounting Global
Settings (New) Ledgers Ledger Define Ledger Group
For each company code and entry code defined, these settings must provide one correct ledger group
containing all the relevant ledgers for the combination.
Result
The system creates or updates the work table for the ledger group. When the account is released [page 365],
the system receives the necessary information to assign the correct ledger group to each posting.
9.2.5.4.2 Determine Counter Readings in CAP Log
Use
A client accounting period (CAP) is a cedent's accounting period. For each accounting period in the treaty, the
CAP log displays the number (counter readings) of final accounts, estimated accounts, and reversed estimate
accounts that are assigned to this period.
The background job Determine Counter Readings in CAP Log recalculates these counter readings in the CAP log
with each run.
You find the background job Determine Counter Readings in CAP Log in Schedule Manager under Run
Accounting Functions.
You can control the background job using the following input parameters:
● Company code
● Treaty class
● Treaty number
● Start of accounting period
The system selects only those treaties that match the company codes, treaty classes, and treaty numbers you
have specified.
It reads the counter values for CAP log entries (in other words, for accounts) where the start of the accounting
period is the same as or after the specified start of accounting period.
Prerequisites
Before you run the background job, you must ensure that you have made the relevant settings in Customizing
for FS-RI Reinsurance under Basic System Forecast and Estimation Edit Combination of Actual and
Estimate for CAP Log .

9.2.5.5 Enter Risk Manager Histories
The background jobs described in this section support you when you enter Risk Manager histories:
● Generation of Complete Histories

● Deletion of Delta Histories
9.2.5.5.1 Generation of Complete Histories (Risk Manager)
Use
The technical name of this background job is /MSG/H_H_HISTORY_ASSEMBLER.
You use this background job to synchronize the delta histories of a policy or an accumulation into complete
histories.
Features
A delta history contains the changed data of the policy or accumulation between two save operations.
It documents the changes made to a policy or accumulation.
A complete history groups the delta histories of a policy or accumulation into a single historical status. The
delta histories are not deleted. The system generates the complete history, including all the assigned objects,
for the most recent status of a policy or accumulation and includes this history after the status of the policy or
accumulation that is open for posting. If the policy or accumulation has never had a status that allows posting,
then the complete history contains the current operational data.
The complete history of an accumulation contains all the policies that have ever been assigned to it. Regardless
of the assignment period, the entire policy and all its periods are included in the complete history.
If one of the policies is assigned to another accumulation, then the system generates a complete historical
status, including all the assigned objects, for this accumulation. This means that all the objects that have ever
been related have the same complete historical status.
 Tip
Depending on your input parameters, this background job can be used to process a large number of
objects. Therefore, we recommend that you schedule this background job outside the online operating
hours of the application to avoid performance problems.

Activities
1. Run the background job with the required input parameters.

3. The system uses the criteria entered by the user to select the policies or accumulations to be processed.
4. The system checks whether a complete history is to be created for each policy and accumulation. An
information message is displayed each time a policy or accumulation is checked.
Result
In addition to the delta histories created by save operations, the history also contains the complete histories
generated by the background job.
Using the complete historical statuses you can run the background job /MSG/H_H_HISTORY_UNDERTAKER to
delete the combined delta histories. In this way, you can reduce the number of historical statuses created for
Risk Manager in-force business data.
9.2.5.5.2 Deletion of Delta Histories (Risk Manager)
Use
The technical name of this background job is /MSG/H_H_HISTORY_UNDERTAKER.
You use this background job to delete the delta histories of a policy or an accumulation.
A delta history contains the changed data of the policy or accumulation between two save operations. It
documents the changes made to a policy or accumulation.
A complete history groups the delta histories of a policy or accumulation into a single historical status.
Prerequisites
The background job deletes the delta historical statuses of a policy or an accumulation provided the related
complete history has been generated.
Complete histories are generated using background job /MSG/H_H_HISTORY_ASSEMBLER. The delta histories
are not deleted.
Features
The background job deletes the delta histories of a policy or an accumulation that have been synchronized into
complete histories. This reduces the number of historical statuses for Risk Manager in-force business data.

When you do so, you can select whether all delta historical statuses older than the most recent complete
historical status are deleted for an object or whether only the delta historical statuses before the first complete
historical status are deleted.
Note that the delta histories of all objects that have ever been related are always deleted together in the same
way as the complete history is generated; the complete history of an accumulation contains all the policies that
have ever been assigned to it.
Delta histories that were generated after the last complete historical status are not deleted.
 Tip
Depending on your input parameters, this background job can be used to process a large number of
objects. Therefore, we recommend that you schedule this background job outside the online operating
hours of the application to avoid performance problems.
Activities
1. Run the background job with the required input parameters.

3. The system uses the criteria entered by the user to select the policies or accumulations to be processed.
4. The system checks whether delta histories can be deleted for each policy and accumulation. The system
displays an information message each time it checks a policy or accumulation.
Result
In addition to the complete histories, the history contains the delta histories generated according to the most
recent complete historical status. The number of historical statuses created for Risk Manager in-force business
data has been reduced.
The complete historical statuses and the delta histories generated after the last complete historical status are
sufficient to ensure that the accounting functions work correctly.
9.2.5.6 Currency Changeover
Use
The following background jobs are available for a currency changeover:
● Execute Currency Changeover
● Analyze Currency Changeover
You can use these background jobs to change an expired currency in policies, treaties, and reinsurance
programs to a successor currency.

Prerequisites
You have defined the expired currency or currencies in Customizing for FS-RI Reinsurance under Basic
System Default Values Currency Changeover (to Euro) Currencies for Changeover .
More Information
For more information about these background jobs, see the documentation for the corresponding reports in
the system.
9.2.5.6.1 Execute Currency Changeover
Use
The technical name of this background job is /MSG/X_CURR_CHGOVER.
You can find the background job in task list /MSG/FSRI0 under FS-RI: General Special Functions
Currency Changeover Execute Currency Changeover .
You can find the background job in task list /MSG/ISRI0 under FS-RI: General Flexibility of Core RI
Processes 3 (BF /MSG/FSRI6) Execute Currency Changeover .
The Execute Currency Changeover background job replaces the currency being changed with its successor
currency at specific places in treaties, policies, and reinsurance programs. Note that the system does not
change currency fields containing dependent amounts. You change these fields and their amounts manually.
Features
Adjustment of Currency Splits
You can use the Execute Currency Changeover background job to add the successor currency to currency splits
in treaties and policies if these currency splits contain the expired currency. This applies to all periods,
regardless of the status of the treaty or policy.
The table below shows how the system adjusts the currency split on the “Currencies” tab page in a treaty or
policy section according to different scenarios. The following abbreviations are used:
● Expired = expired currency
● Successor = successor currency to the expired currency (selected in the background job)
● Other = other valid currency

Original Cur Exchange Rate Account Currency Exchange Rate
rency Type for Currency Type for Ac
count Currency
Scenario 1 Expired Exchange rate type: Expired Exchange rate

expired type: expired
Add Successor Exchange rate type: Successor Exchange rate

expired type: expired
Scenario 2 Expired Exchange rate type: Other Exchange rate

expired type: other
Add Successor Exchange rate type: Other Exchange rate

expired type: other
Scenario 3 Other Exchange rate type: Expired Exchange rate

other type: expired
Update Other Exchange rate type: Successor Exchange rate

other type: expired
Scenario 4 (only in Basic System) <blank> <blank> Expired Exchange rate

type: expired
Update <blank> <blank> Successor Exchange rate

type: expired
Scenario 5 Expired Exchange rate type: Other expired Exchange rate

expired type: other ex
pired
Add Successor Exchange rate type: Other expired Exchange rate

expired type: other ex
pired
Scenario 6 (only in Risk Manager at policy Expired Exchange rate type: <blank> <blank>
section level) expired
Add Successor Exchange rate type: <blank> <blank>

expired
The system does not transfer the Share in % field.
If the Exchange Rate of Main Account field is filled in an entry in the currency split, the system does not transfer
this field to the new data record. The system informs you if this is the case.
In scenario 5 you can change the remaining expired currency to the successor currency by running the
background job again.
Other Currency Adjustments
The system updates the retrocession assignment currency in treaties.

Provided there are no involvement amounts, the system changes the share currency from the expired currency
to the successor currency.
It replaces the period currency in reinsurance programs with the successor currency.
9.2.5.6.2 Analyze Currency Changeover
Use
The technical name of this background job is /MSG/X_CURR_CHGOVER_SHW.
You can find the background job in task list /MSG/FSRI0 under FS-RI: General Special Functions
Currency Changeover Analyze Currency Changeover .
You can find the background job in task list /MSG/ISRI0under FS-RI: General Flexibility of Core RI
Processes 3 (BF /MSG/FSRI6) Analyze Currency Changeover .
The Analyze Currency Changeover background job checks whether specific currency fields within treaties,
policies, or reinsurance programs contain a specific expired currency.
Features
The Analyze Currency Changeover background job evaluates:
● Only the most recent periods:

○ Reinsurance program: most recent start date
○ Treaty: most recent period
○ Policy (occurrence year): most recent start date
○ Policy (underwriting year): most recent underwriting date
● Only periods at treaty level (non-life: periods, life: generations) or at policy level that:
○ Are not reversed
○ Cover the key date (start date of the financial year for each company code) of the currency changeover
or start later
In addition to this, you can use BAdI /MSG/X_CURR_CHGOVER_SHW_BADI to analyze customer-specific fields
and other periods.
For more information about the functional scope of BAdI /MSG/X_CURR_CHGOVER_SHW_BADI, see the
Result
The system determines the following data for the periods found and displays this data in the application log:
1. Reinsurance program: ranks whose rank currency is the expired currency

2. Treaty: involvements whose share currency is the expired currency
3. Treaty: sections whose leading currency is the expired currency

4. Policy: policy sections whose leading currency is the expired currency
5. Policy: participations whose leading currency is the expired currency
In the case of 1 and 2, you have to check all the amounts dependent on the changed currency and, where
necessary, change these manually.
In the case of 3, 4, and 5, the system informs you that you have to check all the amounts dependent on the
changed currency (such as liability data and premium data) and, where necessary, change the amount
manually. The system displays this information message when:
● You change the currency of a section in Basic System. The message is displayed in the treaty dialog at
section level.
● You change the leading currency in Risk Manager Non-Life. The message is displayed at policy section and
participation level.
In addition to this, you can use BAdI /MSG/X_CURR_CHGOVER_SHW_BADI to analyze customer-specific fields
and other periods.
More Information
For more information about the functional scope of BAdI /MSG/X_CURR_CHGOVER_SHW_BADI, see the
9.2.6 FS-RI Interface
The functions described in this section support you when you are using the P2R interface (primary insurance
to reinsurance):
● P2R interface (primary insurance to reinsurance)
9.2.6.1 P2R Interface (Primary Insurance to Reinsurance)
The functions described in this section support you when you generate FS-RI accounts from preliminary
accounts:
● Generation of FS-RI accounts from preliminary accounts

10 Interfaces
SAP Reinsurance Management for SAP S/4HANA provides the following interfaces:
● APIs for Connecting Interfaces [page 564]

● BAPIs for Connecting Systems [page 576]
● P2R Interface for Integration of Primary Insurance [page 580]
10.1 APIs for Connecting Interfaces
Use
SAP Reinsurance Management for SAP S/4HANA provides application programming interfaces (APIs) that can
be used to read, create, and edit the entities of business objects.
The APIs comprise remote-enabled function modules from the technical environment of the supported
business objects.
You can use the APIs primarily to create a customer-specific interface. You can use the remote-enabled
function modules to implement a web-based interface for editing FS-RI data, for example.
Implementation Considerations
Naming Convention
Main packages for each business object are created in the structure package /MSG/82_RFC_SERVICES. Each
main package is named according to the following schema:
● /MSG/82_RFC_UI_<BO>
Packages are created under the main packages for each function type that affects business objects - provided
corresponding functions are available for the business object.
These are named based on the following schema:
● /MSG/82_RFC_UI_<BO>_<AKTION>[_<laufende Nummer (optional)>]
Action Abbreviation Contents
CREATE CRT Functions used to create one or more

(sub)entities of the business object

564 PUBLIC Interfaces
Action Abbreviation Contents
DELETE DEL Functions used to delete one or more

UPDATE UPD ● Functions used to change one or

more entities of the business ob
ject
● This includes the creation, chang
ing, and deletion of subentities
MODIFY MODIFY Functions used to create, change, and

delete one or more entities of the busi
ness object
READ READ Functions used to read one or more

FIND FIND ● Functions used to find data

● Evaluation functions
PROCESS PRC Functions used to process entities of

the business object
Features
For a detailed description of the functions and parameters of each remote-enabled function module, see the
system documentation for the individual function module.
APIs are available for the following business objects:
Business Object Name Mapping of FS-RI Entities Definition
Reinsured Risk [page 572] Risk Manager Non-Life groups with par A reinsured risk contains information
ticipations (no accumulation groups) about the transferred liability and about
the distribution of this liability to reten
tion and reinsurance.

Interfaces PUBLIC 565
Reinsurance Contract [page 573] Reinsurance treaties A reinsurance treaty is an agreement

between a cedent and a reinsurer and
contains information about how risks
are transferred.
The information in a reinsurance treaty

classifies the transfer of risk, specifi-
cally the following aspects:
● Assumed or ceded reinsurance

● Proportional or non-proportional
reinsurance
● Obligatory or facultative reinsur
ance for a single risk
Reinsurance Loss [page 570] Losses In reinsurance, a loss is the occurrence

of a trigger that may be relevant for re
insurance.
A loss contains specific information (for

example, loss location, loss period, loss
class) and information about the han
dling of the loss between the cedent
and reinsurer (for example, the cover
age of losses by obligatory or facultative
reinsurance and loss accounts).
Reinsurance Loss Group [page 571] Loss groups In reinsurance, a loss group groups
losses that belong together. The criteria
that determines whether losses belong
together includes the cause of the loss,
the peril, the loss location, or the period
in which the loss occurred.
A loss group groups losses so that they

can be processed together in the non-
proportional account for a loss event.
Reinsurance Object [page 576] Objects In reinsurance, an object is an object

(tangible or intangible) or a person that
is related to reinsured business.
An object can contain specific informa

tion, such as duration of validity or loca
tion.
Reinsurance Policy [page 571] Risk Manager Non-Life policies In reinsurance, a policy contains an
original risk that is relevant for reinsur
ance.

Reinsurance Policy Group [page 572] Risk Manager Non-Life accumulation In reinsurance, a policy group groups
groups policies that have specific common
properties.
Reinsurance Program Ruleset [page Portfolio treaties and reinsurance pro The ruleset for a reinsurance program
574] gram defines how the liability from risks that
have been transferred for a defined
portfolio section are to be distributed to
retention and reinsurance treaties.
Reinsurance Technical Account [page Technical accounts In reinsurance, an account is a collec

574] tion of postings that occur either in an
obligatory or facultative form depend
ing on the reinsurance business.
An account can group together post

ings according to different criteria, such
as by treaty, currency, loss, or period.
 Caution
A reduced data repository is imported for the function modules for the business objects. This is required
for the checks and functions in the standard system. The system does not have to import all the data
attached to the superior object.
If you have added your own implementations to the standard system, you must check whether the data
repository is sufficient for the use of APIs. If necessary, additional data must be imported.
Final checks and structural checks are not run in the individual APIs. Only those checks are run that are
actually required as a result of the use of APIs.
10.1.1 API Functions: Function Types (Function Groups)
Actions involving the subentities of a business object are stored in the function groups of the related business
object according to the action (Create, Update, Delete, Process, Find, Modify, and Read).
Each remote-enabled module (RFC module) has an input structure for the transfer of parameters, an output
structure for the data to be returned, and a table for the display of messages.
Since the RFC modules can be called via a network connection, the input and output structures are kept as
small as possible so that the transfer times are not affected.
The RFC modules work stateless. The server handles the calls for two RFC modules independently of each
other. All the data that is needed to process an RFC call must be provided by the interface or read from the
database.

Optimistic Locking
An optimistic write lock is used for the affected objects so that the calling environment can be coupled loosely
to the FS-RI system. The absence of pessimistic locks also improves the scale. The input and output structures
are given a version structure that has to be filled for calling the RFC module or is filled by the API.
The version structure contains a date field, a time field, and a time zone field.
The version structure of the output structure in a READ module is filled with the current date and time. The
input structure does not contain a version structure because no data is being changed.
The version structure of the input structure in DELETE, CREATE, UPDATE, and PROCESS modules must be filled
with a valid version of the business object, which has been determined previously using the READ module or
using a current time stamp of the back-end system, for example.
When the system processes the RFC module it compares the version structure of the input structure with the
date and time of the change to the business object, taking into account the time zones. If the date and time of
this change is before the date specified in the version structure, the system continues the process. Otherwise,
this means that the business object has since been changed. The system terminates the process and displays
an error message.
At the end of successful processing, the CREATE, UPDATE, MODIFY, PROCESS, and DELETE modules for
subentities return the version of last save operation in the output structure.
You may want to process RFC modules without a version check because you do not want to import the
business objects for a mass process right now, for example. To do this, you enter the current date and time in
the input structure (or the SAP “high date“). In this case, however, any changes made by other users are
overwritten.
No Changes After Reading
The figure below illustrates the process flow of optimistic locking if no changes are made. The business object
has been changed before the READ module is run. The read module returns the read date and time. The change
date and time are compared with the read date and time when the UPDATE module is run. The system cannot
find any changes to the business object and the UPDATE module is run.

Changes After Reading
The figure below illustrates the process flow of optimistic locking if changes are made. The READ module
returns the read date and time. After the READ module has been run, the business object is changed in the
database. The change date and time of the object are updated. When you call the UPDATES module, the system
compares the read date and time with the change date and time. The system finds that a change has been
made and displays an error message.
Data Repository

The API processes and checks a data repository that is aimed at the relevant technical application scenario.
EXTENSION IN and EXTENSION OUT parameters are available in the API for individual enhancements that you
can process using BAdI implementations.
10.1.2 API Functions: Reinsurance Loss
The following function modules are available for the business object Reinsurance Loss:
Function Module Type Description
/MSG/82_RL_F_BY_ELEMENTS FIND Find losses using search criteria
/MSG/82_RL_F_BY_USER_CHG FIND Find losses most recently edited by cur

rent user
/MSG/82_RL_C_BASIC_DATA CREATE Create the basic data for a loss
/MSG/82_RL_R_BASIC_DATA READ Read the basic data for a loss
/MSG/82_RL_R_RICLAIM READ Read the cedent assigned to a loss
/MSG/82_RL_R_ACTIVITY READ Read the activities for the loss and ce
dent
/MSG/82_RL_R_APPL_COVERAGE READ Read coverages (assigned treaties and

participations) for a loss and cedent
/MSG/82_RL_R_APPL_COV_XOL_DATA READ Read applicable LUDs for a loss and ce

dent based on the coverages
/MSG/82_RL_U_BASIC_DATA UPDATE Change the basic data for a loss
/MSG/82_RL_U_RICLAIM UPDATE Create, change, and delete the cedent

assigned to a loss
/MSG/82_RL_U_ACTIVITY UPDATE Create, change, and delete the activities

for a loss and cedent
/MSG/82_RL_U_EXCESSOFLOSSDATA UPDATE Change applicable LUDs for a loss and

cedent
/MSG/82_RL_P_CLOSE_RICLAIM UPDATE Close a loss for a cedent
/MSG/82_RL_U_APPL_COVERAGE UPDATE Create, change, and delete coverages

(treaty and single risk) for a loss and ce
dent
/MSG/82_RL_P_CANCEL_ACT PROCESS Reverse a closed activity for a loss and

cedent

/MSG/82_RL_P_CLOSE_ACT PROCESS Close activity for a cedent
/MSG/82_RL_P_SIM_CLOSE_RICLAIM PROCESS Simulate the closing of a loss for a ce

dent
/MSG/82_RL_P_CLOSE_RICLAIM_V1 PROCESS Close coverages (treaty and single risk)

and cedents for a loss
/MSG/82_RL_P_VOID_CLAIM PROCESS Reverse loss
10.1.3 API Functions: Reinsurance Loss Group
The following function modules are available for the business object Reinsurance Loss Group:
/MSG/82_RLG_F_BY_ELEMENTS FIND Find loss groups using search criteria
/MSG/82_RLG_C_RILOSSGRP CREATE Create a loss group and assign single

losses
/MSG/82_RLG_R_RILOSSGRP READ Read a loss group and its single losses
/MSG/82_RLG_U_RILOSSGRP UPDATE Change a loss group and create,

change, and delete its single losses
10.1.4 API Functions: Reinsurance Policy
The following function modules are available for the business object Reinsurance Policy:
/MSG/82_RP_P_CALC_LIAB PROCESS Execute liability aggregation for a rein

sured policy
/MSG/82_RP_P_CONF_POL PROCESS Execute confirmation for a reinsured

policy

10.1.5 API Functions: Reinsurance Policy Group
There are no function modules available for the business object Reinsurance Policy Group.
10.1.6 API Functions: Reinsured Risk
The following function modules are available for the business object Reinsured Risk:
/MSG/82_RIRISK_CRT_PRE CREATE Create a prior cession group including

assignments to one or more assumed
participations
/MSG/82_RIRISK_CRT_ALLOC_PRE CREATE Assign an existing prior cession group

to one or more assumed participations
/MSG/82_RR_C_C_P_J_NPF_B CREATE Create a ceded non-proportional, facul

tative participation
/MSG/82_RR_C_C_P_J_NPO_B CREATE Create a ceded non-proportional, oblig

atory participation
/MSG/82_RR_C_C_P_J_PF_B CREATE Create a ceded proportional, facultative

participation
/MSG/82_RR_C_C_P_J_PO_B CREATE Create a ceded proportional, obligatory

participation
/MSG/82_RR_R_C_J_LIABDIST READ Read the coverage data and retention

data of a journal for a reinsured risk
/MSG/82_RR_U_C_J_ADD_RET UPDATE Change the additional retention of a

journal for a reinsured risk
/MSG/82_RR_U_C_P_J_RET UPDATE Change the retention of a journal for a

participation
/MSG/82_RR_U_C_P_J_RT_NPF UPDATE Change the coverage data of a journal

for a ceded non-proportional, faculta
tive participation
/MSG/82_RR_U_C_P_J_RT_NPO UPDATE Change the coverage data of a journal

for a ceded non-proportional, obligatory
participation

/MSG/82_RR_U_C_P_J_RT_PF UPDATE Change the coverage data of a journal

for a ceded proportional, facultative
participation
/MSG/82_RR_U_C_P_J_RT_PO UPDATE Change the coverage data of a journal

for a ceded proportional, obligatory par
ticipation
/MSG/82_RIRISK_PRC_CANCEL_PRT PROCESS Reverse one or more ceded participa

tions
/MSG/82_RR_P_C_GEN_RIRISK PROCESS Create cession groups for a reinsured

policy
/MSG/82_RR_P_C_CALC_CES PROCESS Calculate cessions for a reinsured risk
/MSG/82_RIRISK_DEL_ALLOC_PRE DELETE Delete one or more assignments of one

or more assumed participations to an
existing prior cession group
10.1.7 API Functions: Reinsurance Contract
The following function modules are available for the business object Reinsurance Contract:
/MSG/82_RICON_FIND_BY_USER_CHG FIND Determine reinsurance treaties that

have been changed recently by the user
/MSG/82_RICON_FIND_APP_USER FIND Determine manual and automatic dates

in reinsurance treaties for a user
/MSG/82_RICON_FIND_APP_INV_PAR FIND Determine manual and automatic dates

in reinsurance treaties for a business
partner
/MSG/82_RICON_FIND_APP_CON_ID FIND Determine manual and automatic dates

for a reinsurance treaty
/MSG/82_RICONTRACT_CRT_APP CREATE Create a manual date for a reinsurance

treaty
/MSG/82_RICONTRACT_UPD_APP UPDATE Change a manual date for a reinsurance

treaty

/MSG/82_RICONTRACT_DEL_APP DELETE Delete a manual date for a reinsurance

treaty
10.1.8 API Functions: Reinsurance Program Ruleset
The following function modules are available for the business object Reinsurance Program Ruleset:
/MSG/82_RIP_F_SECTCOV_SC FIND Find the assignment rules for reinsur

ance programs based on structural
characteristics
/MSG/82_RPR_R_TTY_REL_SUB_JRNL READ Read obligatory coverages from a rein

surance program period
10.1.9 API Functions: Reinsurance Technical Account
The following function modules are available for the business object Reinsurance Technical Account in the loss
account:
/MSG/82_RTA_CM_FGU_CLAIM_ACC CREATE Create FGU accounts for a loss and ce

dent
/MSG/82_RTA_C_PREV_CLAIM_ACC CREATE Create preview accounts for a loss and

cedent
/MSG/82_RTA_R_CLAIM_FGU READ Read FGU accounts for a loss and ce

dent or for an activity or based on ac
count numbers
/MSG/82_RTA_R_CL_FGU_BAL_OV READ Consolidated determination of the FGU

account balance for a loss and cedent
that is summarized by structural char
acteristics
/MSG/82_RTA_R_LOSS_OV_ACC_BYE READ Determine loss figures at detailed ac

count level based on search criteria (for
treaty-related accounts only)

/MSG/82_RTA_R_LOSS_OV_BY_ELEM READ Determine loss figures at coverage level

based on search criteria (for treaty-re
lated accounts only)
/MSG/82_RTA_R_LOSS_OV_STRC_BYE READ Determine loss figures at structural

characteristic level based on search cri
teria (for treaty-related accounts only)
/MSG/82_RTA_R_TTY_ACC_BAL_OV READ Consolidated determination of the

treaty figures for a loss and cedent that
are summarized by structural charac
teristics
/MSG/82_RTA_R_CLAIM_FGU_OV READ Read FGU account header data for a

loss and cedent or an activity
/MSG/82_RTA_R_CLAIM_FGU_WP READ Read FGU account and its postings
/MSG/82_RTA_R_C_FGU_BA_BY_E_V1 READ Determine FGU account balance based

on a key date
/MSG/82_RTA_R_LOSS_CALC_OV READ Read preview accounts for an activity

aggregated at coverage level
/MSG/82_RTA_R_LOSS_OV_FLEX READ Use search criteria to determine loss

figures at an aggregation level that can
be configured in a flexible way
/MSG/82_RTA_R_SIM_RES_OV READ Read preview account header data for a

loss and cedent
/MSG/82_RTA_R_SIM_RES_WP READ Read preview account with postings for

a loss and cedent
/MSG/82_RTA_M_CLAIM_FGU MODIFY Create, change, and delete FGU ac

counts for a loss and cedent
/MSG/82_RTA_M_SIM_ACC MODIFY Create, change, and delete preview ac

counts for a loss and cedent
/MSG/82_RTA_P_FGU_RECALC_V1 PROCESS Recalculate a loss using the simulated

redistribution of FGU accounts to a loss
and cedent
/MSG/82_RTA_P_FGU_RECALC PROCESS Recalculate FGU
/MSG/82_RTA_P_CHG_FGU_BAL PROCESS Change FGU account balance for a loss

and cedent

/MSG/82_RTA_P_FGU_ACC_PREVIEW PROCESS Generate a simulated preview from FGU

accounts
/MSG/82_RTA_P_FGU_ACC_PREV_V1 PROCESS Loss calculation using simulated distri

bution of FGU accounts to treaty and
single risk coverages for a loss and ce
dent
/MSG/82_RTA_P_FINAL_ACT_V1 PROCESS Finalize open activity for a loss and ce

dent
/MSG/82_RTA_P_CALC_COND_PREV PROCESS Calculate conditions for preview ac

counts
/MSG/82_RTA_D_FGU_CLAIM_ACC DELETE Delete FGU accounts for a loss and ce

dent
/MSG/82_RTA_D_PREV_CLAIM_ACC DELETE Delete preview accounts for a loss and

cedent
10.1.10 API Functions: Reinsurance Object
The following function modules are available for the business object Reinsurance Object:
/MSG/82_RO_F_BASIC_DATA FIND Find objects using search criteria
/MSG/82_RO_C_BASIC_DATA CREATE Create an object and assign subobjects
/MSG/82_RO_R_BASIC_DATA READ Read an object and its subobjects
/MSG/82_RO_U_BASIC_DATA UPDATE Change an object and its subobjects
/MSG/82_RO_D_BASIC_DATA DELETE Delete an object
10.2 BAPIs for Connecting Systems
Use
SAP Reinsurance Management for SAP S/4HANA (FS-RI) provides Business Application Programming
Interfaces (BAPIs) that can be used to connect external systems to the FS-RI system.

The BAPIs are defined as methods of business object types.
You use business objects to structure business data from a business perspective. A business object is the
technical (software) rendering of a central business object in the real world, such as a treaty.
Features
SAP Reinsurance Management for SAP S/4HANA provides the following BAPIs:
● BAPIs in FS-RI Basic System [page 577]

● BAPIs in FS-RI Risk Manager [page 579]
10.2.1 BAPIs in FS-RI Basic System
Use
To find the BAPIs, start transaction BAPI from the SAP Easy Access screen and choose Financial Services
Reinsurance .
Features
FS-RI Basic System currently provides the following business object types:
Object Type Object Name Description
/MSG/RTTY FsriTreaty (FS-RI treaty) Management of FS-RI treaties
/MSG/RACC Accounting (FS-RI accounts) Management of FS-RI accounts
/MSG/RGRP FsriTreatyGroup (FS-RI treaty group) Management of FS-RI treaty groups
/MSG/RLOSS FsriLoss (FS-RI loss) Management of FS-RI losses
The following methods are currently available in the business object types:
Methods in Business Object Type /MSG/RTTY
Method Function
CreateNotice Copies FS-RI treaty notes
Delete Deletes an FS-RI treaty

Method Function
ExistenceCheck Checks whether the FS-RI treaty exists
GetDetail Finds FS-RI treaty data
GetList Displays a list of FS-RI treaties
ModifyMultiple Mass processing for creating/changing FS-RI treaties
Methods in Business Object Type /MSG/RACC
Method Function
CreateNotice Copies FS-RI account notes
CreateStatistic Creates statistics for FS-RI account
GetDetail Finds FS-RI account data
GetList Displays a list of FS-RI accounts
KkDocCreate Generates open items for the current account system
ModifyMultiple Mass processing for creating or changing FS-RI accounts
Release Releases an FS-RI account
Reverse Reverses an FS-RI account
Methods in Object Type /MSG/RGRP
Method Function
ExistenceCheck Checks whether the FS-RI treaty group exists
GetList Finds the list of existing FS-RI treaty groups
GetDetail Finds FS-RI treaty group data
Modify Creates or changes an FS-RI treaty group
Methods in Object Type /MSG/RLOSS
Method Function
CreateLog Creates the text and entries for the loss log
CreateNotice Copies FS-RI loss notes

Method Function
Delete Deletes an FS-RI loss
ExistenceCheck Checks whether the FS-RI loss exists
GetList Displays a list of FS-RI losses
GetDetail Finds FS-RI loss data
ModifyMultiple Mass processing for creating or changing FS-RI losses
 Note
You can make the specific Customizing settings that are relevant for the execution of the BAPI methods
under FS-RI Reinsurance Basic System Interfaces FS-RI Interface .
10.2.2 BAPIs in FS-RI Risk Manager
Use
To find the BAPIs, start transaction BAPI from the SAP Easy Access screen and choose Financial Services
Reinsurance .
Features
FS-RI Risk Manager currently provides the following business object types:
Object Type Object Name Description
/MSG/HOBJ Objects (FS-RI objects) Management of FS-RI objects
/MSG/HRISK Risk (risk) Management of policies and accumula

tion groups
Methods in Business Object Type /MSG/HOBJ
Method Function
CreateNotice Copies FS-RI object notes
ExistenceCheck Checks whether FS-RI object exists

Method Function
GetDetail Finds FS-RI object data
GetList Searches for FS-RI objects using existing criteria
ModifyMultiple Mass processing for creating/changing FS-RI objects
Methods in Business Object Type /MSG/HRISK
Method Function
CreateNotice Creates Risk Manager notes
ExistenceCheck Checks whether the object exists
GetDetail Finds data for a policy or group
GetList Gets a list of all existing policies
ModifyMultiple Creates or changes a risk
10.3 P2R Interface for Integration of Primary Insurance
Use
The primary-to-reinsurance interface (P2R interface) supports the process of ceded reinsurance in non-life
business. This interface provides SAP Reinsurance Management for SAP S/4HANA (FS-RI) with a uniform
entry point for data from any primary insurance systems.
The P2R interface identifies the existing reinsurance cover or the required cover for your in-force primary
insurance business. When you release accounts and losses in the primary insurance system, it generates the
corresponding data in the reinsurance system.
As such, the P2R interface simplifies the connection between ceded business and reinsurance.
Implementation Considerations
The P2R interface provides you with a functional framework that specifies exactly which data must be provided
by the primary insurance system and in what form. The P2R interface works with accumulations defined in the
primary insurance system.
In Customizing, you can make the settings for processing the delivered data.

Integration
The P2R interface is part of the FS-RI system. It checks whether the primary insurance data received is relevant
for reinsurance and forwards any reinsurance-relevant data to Risk Manager Non-Life or Basic System,
depending on the Customizing settings. The accumulations from the primary insurance system are transferred
to the FS-RI system.
Features
The features of the P2R interface include the transfer of in-force business data and loss and account data
(premiums and losses). This data is checked to determine its relevance for reinsurance and is handled
differently depending on the result. You define the criteria for this check when you configure the interface.
The P2R interface uses the following types of reinsurance.
1. No reinsurance
The primary insurance sections (policy sections) delivered to the interface are not reinsured. Neither in-
force business data nor loss and account data is created in the FS-RI system.
2. Reinsurance in Risk Manager
The structural characteristics and liability data from the primary insurance system are transferred to Risk
Manager Non-Life and the transferred liability is distributed to the ceded business side. Accounts and
losses are created in the FS-RI system with reference to the transferred liability data.
3. Reinsurance in Basic System
The structural characteristics and liability data from the primary insurance data are not transferred to the
FS-RI system. Accounts and losses are generated in the covered master treaty for the accounts and losses
from the primary insurance system.
Error Handling Using the Postprocessing Office
The Postprocessing Office (PPO) is used to support the rational processing of events that originate in any
business process. Error handling using the Postprocessing Office makes it easier to handle errors that occur
during the transfer of data.
Constraints
Deletion of Data via the Interface
The deletion of data in the FS-RI system via the interface is not supported. If in-force business data has been
delivered that you want to discard, you can do this using a reversal. If you want to discard accounts that have
already been transferred to the FS-RI system, you can only do this using an offsetting entry. Losses stay in the
FS-RI dataset; accounts for losses are handled in the same way as other accounts.
Manual Changes to Data from the Interface
Manual changes made to in-force business data or loss data delivered via the interface are overwritten by the
interface when you re-deliver data to the relevant fields.

 Recommendation
Therefore, we recommend you change primary insurance data delivered via the interface in the delivery
system only and then import these changes via the interface.
Changes to Structural Characteristics
The interface does not support changes made retroactively to the structural characteristics (such as class of
business and area) of delivered objects. For example, if you want to change the class of business for a section,
you have to reverse the section via the interface and deliver a new section.
Migration
The P2R interface is not intended to be used to migrate data from other reinsurance or in-force business
systems.
Intra-Company Reinsurance
The reinsurance between companies of primary insurance accumulations that were created using the P2R
interface is not supported in FS-RI Risk Manager Non-Life.
10.3.1 Configuration of the P2R Interface in the FS-RI System
Use
In this process you configure your primary insurance system to provide data and your FS-RI reinsurance
system to receive data. This ensures that you meet the prerequisites for transferring data using the P2R
interface.
Process
Mapping the Reinsurance Business
Creation of the Reinsurance Treaties
So that primary insurance sections can be reinsured using the FS-RI solution, you must assign these to a
pseudo assumed treaty [page 587] in the FS-RI system. These pseudo assumed treaty must be covered by
ceded treaties.
Structure of Primary Insurance Business with PTF Treaties
To specify the type of reinsurance for each part of your primary insurance business ("Reinsurance in Basic
System", "Reinsurance in Risk Manager", or "No Reinsurance"), you must create one or more portfolio treaties
[page 586] that divide the business.
If the usage type is Risk Manager Non-Life, you must enter these portfolio treaties with reinsurance programs.
For more information, see Settings for Reinsuring P2R Business [page 584].
Customizing the FS-RI System

You must decide how you want the FS-RI system to handle the imported data.
For more information, see Settings for Connecting the Primary Insurance System [page 588].
Archiving
A template for an archiving object for the accumulation is available. You must make more detailed settings in
the customer project.
Result
The FS-RI system is ready to transfer and process data via the P2R interface.
10.3.1.1 Mapping of Primary Insurance Values to Reinsurance

Values
Use
You create the congruence between the primary insurance system and the FS-RI system that is needed to
reinsure your business in the FS-RI system. You also assign the structural characteristics from the primary
insurance system to the structural characteristics in the FS-RI system.
Prerequisite
● You have specified the systems with which you are working in the P2R interface (see Settings for
Connecting the Primary Insurance System [page 588]).
Procedure
The Customizing node Mapping Customizing contains the interface attributes that need to be mapped. The
following example using classes of business shows how you map these attributes:
1. Identify the classes of business that you use in the primary insurance system and for which you want to
create reinsurance cover via the P2R interface.
2. Check whether these classes of business have been created in the FS-RI system and create any missing
classes of business. You do this in Customizing for FS-RI Reinsurance under Basic System Treaty
Classes/Lines of Business Edit Classes of Business .
3. Assign the primary insurance classes of business to the FS-RI classes of business. To do this, use the
parameters that were delivered by the primary insurance system to the P2R interface. You find the settings
in Customizing under FS-RI Reinsurance FS-RI:P2R Interface Mapping Customizing Enter Mapping
for Classes of Business .

Fields that are defined as mandatory entry fields on the interface must be mapped. This is not required for
optional fields that are not being delivered.
 Note
Mapping is also required if the field values in the FS-RI system and in the primary insurance system are
identical (primary insurance class of business “Fire” – reinsurance class of business “Fire”).
Result
The FS-RI system is configured to map the structure of the business to be reinsured.
10.3.1.2 Settings for Reinsuring P2R Business
Context
The P2R interface can analyze the structural characteristics of the transferred business and assign the
corresponding type of reinsurance in Basic System or Risk Manager Non-Life or exclude this business from
reinsurance in the FS-RI system.
This process illustrates how you structure the different distribution rules that are used by the FS-RI system to
assign and post the correct reinsurance treaties.
Procedure
1. Structure of primary insurance portfolio
In the first step, you structure your primary insurance portfolio into one or more pseudo assumed treaties
[page 587]. The primary insurance portfolio must be grouped into pseudo assumed treaty sections
according to the combinations of structural characteristics. These sections are handled together when you
assign assumed accounts.
If the business is to be reinsured in Basic System, you need the pseudo assumed treaty to assign assumed
accounts and distribute these further using treaty calculation rules [page 329] or participating treaties
[page 328] (see below).
If the business is to be reinsured in Risk Manager, you need the pseudo assumed treaty to assign parallel
accounts that illustrate the balance of the assumed business in relation to treaty sections.
2. Structure of reinsurance portfolio
So that you can specify the type of reinsurance (Basic System or Risk Manager Non-Life) for your primary
insurance business, you must first group the primary insurance business to be transferred to the FS-RI

system according to the combinations of structural characteristics that are to be handled together in the
reinsurance business in the FS-RI system.
 Example
You can specify that product liability insurance for Germany and France is reinsured in Basic System
but that product liability insurance for the United States is reinsured in Risk Manager. In this case, you
would group the class of business Product Liability Insurance with the regions Germany and France in
one combination and the class of business Product Liability Insurance with the region United States in
another.
You structure your reinsurance portfolio by creating a portfolio treaty. A section is created in this portfolio
treaty for each combination of structural characteristics required. The structural characteristics that you
assign to the section determine which primary insurance sections are assigned to the section. The Type of
Reinsurance checkbox on the Section tab page under Structure Elements determines whether the primary
insurance sections assigned to this section are reinsured in Basic System or Risk Manager or whether
these are not reinsured in the FS-RI system.
 Note
○ If the creation of a section is requested via the interface but the risk is only reinsured in Basic
System, the system reports that a section was not created because this is not required for
reinsurance in Basic System. In this case, this message is regarded only as a note.
○ If you want to reinsure a primary insurance accumulation in Risk Manager regardless of the
settings in the portfolio treaty, you deliver this accumulation to the FS-RI system with the Manual
Reinsurance checkbox activated. As soon as Manual Reinsurance has taken place, the system
transfers all future deliveries for this accumulation to Risk Manager. This checkbox overrides the
rules from the portfolio treaty governing the accumulation.
Primary insurance accumulations stored in Risk Manager remain in Risk Manager, even if
subsequent changes are delivered without the Manual Reinsurance setting.
3. Make settings for reinsurance in Basic System
You do not enter a reinsurance program for portfolio sections for which you have entered “Basic System”
as the type of reinsurance. In this case, you use treaty calculation rules or participating treaties to assign
the ceded master treaties to the pseudo assumed treaty sections [page 587].
4. Make settings for reinsurance in Risk Manager
You enter a reinsurance program [page 690] in the portfolio treaty for the portfolio sections for which you
have entered “Risk Manager” as the type of reinsurance. In the reinsurance program, you define how the
liability is distributed to the ceded treaties and retention.
5. Make settings for no reinsurance in the FS-RI system
You do not need to make any further settings for portfolio sections for which you have entered No
Reinsurance as the type of reinsurance.
Results
The FS-RI system is configured to identify which type of reinsurance is to be selected for a delivered section.
This means that when a new section is delivered that is to be covered in Risk Manager, the system can generate
the required sections; when an assumed account is delivered, it posts the corresponding reinsurance treaties.

If a section is delivered that is to be covered in Basic System, no data is created in the FS-RI system; if an
assumed account is delivered, the system posts the corresponding reinsurance treaties.
If sections are delivered with the setting No Reinsurance, no data is created in the FS-RI system.
10.3.1.2.1 Portfolio Treaty in the P2R Interface
Definition
The portfolio treaty (PTF treaty) is an FS-RI treaty that does not map a business relationship but is used to
structure the ceded business.
Use
When you use the P2R interface, you specify for each PTF section whether the section is reinsured using the
structural characteristics in Basic System or in Risk Manager or whether it is not covered by the FS-RI system.
In the master data under “Default Values for Risk Manager” -> “Default Values for Treaty”, you must enter a PTF
treaty for each partner or class of business. You can use a PTF treaty for your entire business or any number of
individual treaties for each partner or class of business.
If the sections are reinsured in Risk Manager, you also enter in the PTF section the reinsurance program [page
690] to be used.
For more information, see Portfolio Treaty [page 92] in Risk Manager.
Retrospective Changes
If you have already delivered data via the P2R interface, you can make retrospective changes to portfolio
sections only with the following restrictions:
● Change to period of PTF treaty

● Change to reinsurance program in the PTF treaty section
● Change to the validity period of the reinsurance program
After you have made these changes, you must execute the Recalculate Conditions Risk Manager background
job; this job makes the required adjustment postings.
 Caution
Changes to the structural characteristics, to the Type of Reinsurance checkbox, and to the premium mode
are not supported.

10.3.1.2.2 Pseudo Assumed Treaty
Definition
A pseudo assumed treaty is an assumed treaty that does not map the business relationship with a cedent but
maps the structure of the business generated in the owner company.
Use
When you transfer an account from the primary insurance system, the structural characteristics of the account
determine the section of the pseudo assumed treaty to which data is posted.
You can enter treaty calculation rules or participating treaties for each section. These determine the ceded
treaties to which data is posted and the shares that remain in the retention.
Structure
For pseudo assumed treaties, you must define a specific treaty category in Customizing with an assumed
direction and set the Statistical checkbox. The cedent for the pseudo assumed treaty is always the owner
company, which represents the individual policyholders.
In the master data under Default Values for Risk Manager Default Values for Treaty , you must enter a
pseudo assumed treaty for each partner and class of business. You can use a pseudo assumed treaty for your
entire business or any number of individual treaties for each partner and class of business.
Sections
Since each posting transferred via the P2R interface must be covered by a pseudo assumed treaty, every
expected combination of structural characteristics must be covered by one pseudo assumed treaty section. As
such, the pseudo assumed treaty section must comprise only the share of the existing business to be handled
equally in the FS-RI system on the assumed side.
 Example
You use your primary insurance system to process fire and storm insurance for Germany and Austria. In the
FS-RI system, you want to handle the primary insurance for storm insurance in Germany and Austria
together and separate the fire insurance for each country.
You need three pseudo assumed treaty sections; section 1 covers the class of business “Storm” and the
areas “Germany” and “Austria”, section 2 covers the class of business “Fire” and the area “Germany”,
section 3 covers the class of business “Fire” and the area “Austria”.

10.3.1.3 Settings for Connecting the Primary Insurance
System
Prerequisites
● You have specified which system you want to work with in the P2R interface and have defined a unique
system ID for each of these systems that is to be used by the primary insurance system and by the FS-RI
system. You can also define multiple logical systems for a physical primary insurance system. To do this,
you must configure your primary insurance system in such a way that it provides a specific system ID for
each logical system required.
● You have defined the structural characteristics [page 583] to be used in the P2R interface.
Context
You register your primary insurance system in the P2R interface and make the required settings for this system
as follows.
Procedure
1. General system settings
1. In Customizing for Risk Manager (Internal) 6.00 under Central Settings Edit Lock Indicator for
Status Transition , set the lock indicator for status transition to Passive.
2. In Customizing for FS-RI Reinsurance under FS-RI Risk Manager (Non-Life) Group Management
Edit Group Categories , create a group category with the following characteristics:
○ Level ID: "Cession with Journal"
○ Type: “Primary Insurance Group”
This group category is used for the cession groups created via the interface.
3. Set the Warning checkbox in Customizing for FS-RI Reinsurance under Basic System Interfaces
FS-RI Interface General Parameters . If you do not and you are reinsuring business in Risk Manager
the entire delivery is discarded if there is an unplaced risk requiring facultative cover.
2. Register primary insurance system in FS-RI system
1. Open the Customizing activity Enter Central Settings under FS-RI Reinsurance FS-RI: P2R
Interface .
2. Create a new entry. As the system ID, enter the same name for the primary insurance system that is
transferred from your primary insurance system to the interface. Indicate whether you are using the
Postprocessing Office [page 591].

 Note
You cannot enter the system ID at a later date.
3. In the subfolders, enter the partner used by the system. This information is needed to find the correct
company code of new objects created in the FS-RI system via the interface.
4. Repeat steps 2 and 3 for each delivery system.
3. Define status and change reasons
Objects created or processed via the interface must have a status and change reason.
In Customizing for FS-RI Reinsurance under FS-RI: P2R Interface Enter Processing Statuses for In-Force
Business , you enter the status to be assigned to the objects by the interface.
Enter a status for Risk Manager Non-Life objects for different activities. This status must have already been
defined in the FS-RI system (in Customizing for FS-RI Reinsurance under FS-RI Risk Manager (Non-Life)
Policy Administration Edit Statuses ).
In Customizing for FS-RI Reinsurance under FS-RI: P2R Interface Enter Processing Statuses for Loss ,
enter a status for Risk Manager Non-Life objects for different activities. This status must have already been
defined in the FS-RI system (in Customizing for FS-RI Reinsurance under Basic System Loss Edit
Loss Statuses ).
4. Master data
Before you edit the master data for the P2R interface, you must edit the following activity in Customizing
for FS-RI Reinsurance under FS-RI: P2R Interface Assign Partner to Classes of Business .
In the master data, assign the pseudo assumed and portfolio treaties to be used in the P2R interface for
each partner and class of business (under Default Values for Risk Manager Default Values for Treaty ).
Here you also specify whether parallel accounts are to be generated. This means that if you are reinsuring
business in Risk Manager and distribute an account to the ceded business side, the system also posts the
original assumed amount to the pseudo assumed treaty in a parallel account. You can use this to compare
assumed and ceded posting data.
10.3.1.3.1 Settings for External References
Use
When a business object is generated via the P2R interface for a business object in the primary insurance
system (for example, accumulation), the FS-RI system always provides the FS-RI business object with external
references [page 723] that allow you to assign the FS-RI business object to the business object in the primary
insurance system.

Features
Define External Reference Categories
The following references are supported on the interface:
● System ID: A unique ID that identifies the primary insurance system from which the FS-RI object originates.
● Policy ID: A unique ID that identifies the primary insurance policy to which the FS-RI object is assigned.
● Section ID: A unique ID that identifies the primary insurance section to which the FS-RI object is assigned.
The references listed in the following tables are stored in the individual FS-RI objects: For more information
about creating external references for an account, see Generation of FS-RI Accounts from Preliminary
Accounts [page 605].
External References in FS-RI Objects
FS-RI Business Object System ID Policy ID Section ID
Accumulation Group X X X
Account (X)
Loss X
To be able to make this assignment, you must define an external reference category for the connected primary
insurance system. You do this as follows:
1. Create the external reference category (in Customizing for FS-RI Reinsurance under Basic System
Default Values Edit External Reference Categories ). The area of the external reference category must
correspond to that of the business object. This means, for example, that you need you need three external
reference categories for the system ID; one from each of the areas Account, Group, and Loss. So that an
external reference category can be used for the P2R interface, do not set any of the following checkboxes:
Unique Category, Unique Object, Interface Category, and Search Indicator. For more information about
creating external reference categories, see External References [page 723].
2. Assign the external reference category to the primary insurance system (in Customizing for FS-RI
Reinsurance under Integration of Primary Insurance Assign External Reference Categories ).
 Tip
We recommend that where possible you use the IDs for the objects delivered in the primary insurance
system as external reference IDs. This makes it easier to assign objects in the FS-RI system to objects
in the primary insurance system. You make this setting when you configure your primary insurance
system.
If you are integrating several policy systems via the P2R interface, you can ensure that the primary
insurance policies are uniquely encrypted across all the systems provided:
○ You have configured the system in such a way that external references are created for the primary
insurance policies for accounts if you create FS-RI accounts from preliminary accounts.
○ You use these external references to find the accounts for primary insurance policies.
If you are integrating several loss systems via the P2R interface, you can ensure that the losses are
uniquely encrypted across all the systems.

 Example
A policy with the ID “ABC” and with a coverage with the ID “123” exists in the primary insurance system
PI1.
The primary insurance system generates a section in the FS-RI system for this coverage via the
interface. This section is provided with the following external references:
○ Reference category “Coverage ID in Legacy System”, reference ID “123”
○ Reference category “Policy ID in Legacy System”, reference ID “ABC”
○ Reference category “Legacy System”, reference ID “PI1”
You can use this information to assign the section uniquely to its original policy and to its original
coverage in the original system.
10.3.1.4 Error Handling Using the Postprocessing Office
Use
The Postprocessing Office (PPO) is used to support the rational postprocessing of events that originate in any
business process. All the data relevant for processing events is combined in a postprocessing order. You can
process error messages from mass runs of different object types, for example. Processing can be across
systems and components.
In the P2R interface, you can classify error situations according to whether they can be rectified. A distinction is
made between errors that can be rectified and those that cannot and between data delivered directly from a
primary insurance system and data that was postprocessed in the Postprocessing Office.
Postprocessing
If data is returned to the P2R interface from the PPO, this is regarded as postprocessing. In all other cases, data
is delivered from the primary insurance system.
Rectifiable Errors
Rectifiable errors are errors that arise primarily as a result of missing entries in Customizing for the interface.
You can only continue to process the data if an administrator fixes the cause of the error in the reinsurance
system. If the PPO has been activated, the data is stored temporarily until it has been corrected and processed
successfully.
Non-Rectifiable Errors
Non-rectifiable errors are errors that can only be fixed by changing the data delivered by the primary insurance
system. Since you cannot change this primary insurance data in the reinsurance system, the error cannot be
fixed and the data is not stored temporarily.
Integration
When rectifiable errors occur, you can use the PPO to keep the interface delivery in shadow tables until the
error situation has been corrected. If you have not activated the use of the PPO in the central settings, the

system handles rectifiable errors in the same way as non-rectifiable errors. This means that the delivered data
is not stored temporarily in shadow tables.
When data is delivered from the primary insurance system, the system checks whether the PPO already
contains entries for the business object. If this is the case, the system saves the data being delivered without
making any further checks. This ensures that the data is transferred to the reinsurance system in exactly the
same order as it is delivered from the primary insurance system.
During postprocessing, the system checks the current postprocessing order to make sure that there are no
older and incomplete postprocessing orders for the business object.
You indicate whether the PPO is activated for each connected primary insurance system in Customizing for the
P2R Interface under Mapping Customizing Enter Central Settings .
 Recommendation
We recommend you use the PPO only if you are using the interface asynchronously because the calling
process cannot react immediately to rectifiable technical errors.
If the interface is being used synchronously, the calling process can be interrupted to handle errors. This
means that it is not necessary to postprocess errors from the PPO.
Dependencies
● The project must process in-force business first and then premium accounts.
● The project must process losses first and then loss accounts.
Features
Postprocessing Orders
Postprocessing orders are created in the PPO when the system finds rectifiable errors in the data delivered
from the primary insurance system and the PPO has been activated. A postprocessing order contains
information about the business object, about which business process caused the error, and a description of the
error.
The following tables illustrate the situations in which postprocessing orders are created or in which new error
situations are added to existing postprocessing orders. In addition to the error category, error handling
depends on whether the PPO has been activated and who is calling the P2R interface.
Error Handling If PPO Has Been Activated
Error Category Delivery from Primary Insurance Sys Delivery from PPO
tem
Rectifiable New postprocessing order Enhancement of postprocessing order
Non-rectifiable No postprocessing order Enhancement of postprocessing order
Error Handling If PPO Has Been Deactivated

Error Category Delivery from Primary Insurance Sys Delivery from PPO
tem
Rectifiable No new postprocessing order Enhancement of postprocessing order
Exception: If a postprocessing order al

ready exists for the business object, an
other postprocessing order is created
even if the PPO has been deactivated.
Non-rectifiable No postprocessing order Enhancement of postprocessing order
 Note
Note that when a business object is delivered from the primary insurance system, the system checks
whether there is an incomplete postprocessing order for this business object. If this is the case, the system
creates a new postprocessing order for the current delivery without making any further checks and imports
the data into the shadow tables.
 Recommendation
We recommend that you handle all unfinished postprocessing orders before you deactivate the PPO.
Otherwise, the data for business objects that have unfinished postprocessing orders cannot be processed
correctly.
You can edit postprocessing orders in transaction /SAPPO/PPO2. Every postprocessing order contains a
description of the error that lead to its creation.
The postprocessing orders are grouped in a directory structure in the PPO desktop, according to which the
functional scope of the relevant P2R interface can be identified. The following table shows the P2R functions
and the corresponding directory node (main object key).
P2R BAPI Main Object Key in Postprocessing Desktop
Preliminary accounts – create FS-RI-PII-ACT_CRT01
Loss – create FS-RI-PII-CLM_CRT
Loss – change FS-RI-PII-CLM_CHG
Accumulation – create FS-RI-PII-NACC_CRT
Accumulation – change FS-RI-PII-NACC_CHG
Once a postprocessing order has been set to In Process, the following options are available.
Processing Options
Repeat
The system reads the delivery data from the shadow tables and tries to import the data into the FS-RI system
again. If the cause the previous error has not been fixed or a new error situation has been identified, the data is
not transferred to the FS-RI system. A description of the new error is added to the postprocessing order. Note

that a new error situation can also arise from a non-rectifiable error. For more information, see the input help
for the Error Category field. If postprocessing is completed without errors, the system deletes the delivery data
from the shadow tables and confirms the postprocessing order. If there are multiple postprocessing orders for
a business object, you must edit these in the order in which the data was originally delivered from the primary
insurance. This is checked when you call the processing option.
Confirm
The delivery data is not transferred to the reinsurance system. The system confirms the postprocessing order
without making any further checks and deletes the data from the shadow tables. The technical behavior of this
processing option is the same as for the Discard option. The difference lies in the meaning of the action. For
example, it could be the case in a company that the Confirm option means that the administrator has manually
entered the data into the reinsurance system.
Discard
The delivery data is not transferred to the reinsurance system. The system confirms the postprocessing order
without making any further checks and deletes the data from the shadow tables. The technical behavior of this
processing option is the same as for the Confirm option. The difference lies in the meaning of the action. For
example, it could be the case in a company that the Discard option means that the primary insurance system
re-delivers the data.
Processing Log in Application Log
The messages created during processing are saved to the application log (transaction SLG1) regardless of
whether the PPO has been activated. In the application log, these messages are subdivided into objects and
subobjects. The following table illustrates the structure of the application log.
Structure of Application Log
Object Subobject Description
/MSG/PII_APPL_ACC P2R interface: accumulation
CHG Change accumulation
COV Accumulation coverage information
CRT Create accumulation
DET Accumulation: detailed information
/MSG/PII_APPL_ACT P2R interface: account
CRT Generation of FS-RI accounts from pre

liminary accounts
/MSG/PII_APPL_CLM P2R interface: loss
CHG Change loss
CRT Create loss

Constraints
If you deactivate the PPO, the system still checks whether there are unprocessed postprocessing orders for the
business object. If this is the case, the system creates a corresponding error message, terminates processing,
and creates a new postprocessing order.
If you are using the interface asynchronously, the PPO should be activated; if you are using the interface
synchronously, the PPO should be deactivated.
10.3.2 Configuration of the P2R Interface in the PI System
Use
This process explains the prerequisites that must be met by your primary insurance (PI) system to ensure that
it provides the P2R interface with the correct information. It also refers to the required format and scope of the
data that must be delivered by the primary insurance system.
Prerequisites
● The primary insurance system has functions for accumulation formation and liability aggregation.
● You have determined the class of business, areas, and so on, to be used by the P2R interface.
● You have made the mapping [page 583] settings.
Process
The P2R interface consists of a collection of BAPIs. You must configure your primary insurance system in such
a way that it calls these BAPIs correctly. The detail of this configuration depends on your primary insurance
system.
The BAPIs are called as per the standard BAPI function. The content that must be delivered to the BAPIs
depends on the use case and BAPI. For more information about which use cases are supported and how data is
exchanged, see Use Cases for the Interface (BAPIs) [page 596].
Result
The primary insurance system can call the P2R interface as part of the use cases supported.

Example
When you create an accumulation in the primary insurance system, you want a “Check RI” button to be
available that checks the reinsurance cover of the primary insurance policy.
You implement this button in the required place in your primary insurance system and connect it using the
corresponding BAPI call. You also implement a report in the primary insurance system that formats the
information for the user returned by the FS-RI system.
10.3.3 Use Cases for the Interface (BAPIs)
Use
The P2R interface comprises multiple use cases that support the exchange of data between the primary
insurance system and FS-RI in typical business processes.
Features
The following tables provide an overview of the existing use cases.
Each use case for the P2R interface is implemented by a Business Application Programming Interface (BAPI).
Each BAPI can transfer a specific amount of data. Some of this data must be delivered while other data is
optional. For a list of the data that must be delivered by the primary insurance system for each use case and for
more information, see the documentation for the individual use cases.
For technical information about the BAPI method, see the documentation for the BAPI. To open this
documentation:
1. Open BAPI Explorer (transaction BAPI).

2. Find the required BAPI in the BAPI hierarchy under Financial Services Reinsurance .
3. Select the BAPI method and choose the Documentation tab page.
Use Cases for the P2R Interface – In-Force Business

Use Case Event in Primary Insurance Event in FS-RI System BAPI Method
System
Use Case: Create Accumula A new accumulation is cre RI in Basic System /MSG/BAPI_
tion [page 599] ated. RIACC_CREATE
The system identifies the
master treaty that covers the
accumulation group. Data is
not created.
RI in Risk Manager Non-Life
An RI accumulation group is
created for the primary insur
ance accumulation.
Use Case: Change Accumula An accumulation is changed. RI in Basic System /MSG/BAPI_

tion [page 601] RIACC_CHANGE
No action.
The corresponding accumu

lation group is changed. The
following changes can be
made:
● Change to the general

data for an accumula
tion
● Change to the general
data for an accumula
tion
● Change to the existing
general section data for
an accumulation section
● Change to the existing li
ability data for an accu
mulation
● Change to/deletion of
existing assignments
between sections and an
accumulation
● Reversal of the existing
assignments between
sections and an accu
mulation
● Creation of new sections
for an accumulation
● Creation of new assign
ments between sections
and an accumulation

System
Use Case: Accumulation In Information is requested RI in Basic System /MSG/

formation [page 602] about the existing reinsur BAPI_RIACC_GETDETAIL
The system displays an error
ance cover assigned to an ac
message because no accu
cumulation.
mulation has been created
for RI in Basic System.
The FS-RI system returns de

tailed information about the
accumulation to the primary
insurance system via the in
terface (see details).
Use Case: Coverage Check Information is requested The FS-RI system returns in /MSG/
for Accumulation [page about the reinsurance cover formation to the primary in BAPI_RIACC_CHECKCOVERA
603] for a hypothetical primary in surance system via the inter GE
surance accumulation. face about whether and how
this accumulation could be
covered by FS-RI.
No data is created in the FS-

RI system.
Use Cases for the P2R Interface – Account
System
Use Case: Create Account An account is created. RI in Basic System /MSG/BAPI_RIACT_CREATE

[page 603]
A preliminary account is cre
ated for a pseudo assumed
treaty.
A preliminary account is cre

ated for a section.

System
Use Case: Create Multiple Multiple account data re RI in Basic System /MSG/
Accounts [page 607] cords are created and trans BAPI_RIACT_CREATEMULTI
Any number of preliminary
ferred to the interface to PLE
accounts are created for
gether in a denormalized
pseudo assumed treaties.
form.
Any number of preliminary

accounts are created for sec
tions.
Use Cases for the P2R Interface – Loss
System
Use Case: Create Loss [page A loss is created. A preliminary loss is created. /MSG/
608] BAPI_RICLAIM_CREATE
Use Case: Change Loss [page Data for a loss is changed. The preliminary loss or loss /MSG/
609] currently assigned to the pri BAPI_RICLAIM_CHANGE
mary insurance loss is
changed. (You cannot create
a loss using this BAPI
method.)
10.3.3.1 Use Case: Create Accumulation
In the Create Accumulation use case (BAPI method /MSG/BAPI_RIACC_CREATE), the P2R interface first
determines whether the accumulation from the primary insurance system is to be reinsured in Basic System or
in Risk Manager.
Objects Created in Basic System
If the accumulation is to be reinsured in Basic System, no data is created in the FS-RI system.

Objects Created in Risk Manager
If the accumulation is to be reinsured in Risk Manager the P2R interface enters the following data from the
primary insurance system for each accumulation:
● An accumulation group with a cession group, for which cessions are calculated and confirmed as soon as
the group is created unless it is delivered with the Manual Reinsurance checkbox
● Any number of sections for the accumulation group
Accumulation Group
The accumulation group created contains the coverages or sections from the primary insurance system as
sections in the FS-RI system. Each coverage or section delivered from the primary insurance system must
contain information about the accumulation group to which it belongs.
Additional accumulation control is not possible in Risk Manager Non-Life.
To specify the responsibilities, create an implementation for the enhancement spot /MSG/
8_PIIX_RESPONSIBILITIES.
Section
The P2R interface creates a section for each primary insurance coverage in the FS-RI system. This section
fulfils the same function in Risk Manager Non-Life as the RM policy section with a policy section group and
participation but has a reduced data scope.
The section contains the following data:
● Section ID
● Reference to the primary insurance policy
● Reference to the primary insurance coverage
● Structural characteristics
● Assignment period for accumulation
Interface Parameters
For a functional description of each interface parameter, see the field help for this parameter.
Messages (table)
Error and success messages are returned using the SAP structure BAPIRET2. provided for BAPIs.
Enhancements
You can make customer-specific enhancements using the SAP structure BAPIPAREX provided for BAPIs via the
EXTENSIONIN parameter and by implementing the enhancement spot /MSG/8_PIIH_EXTENSION.

10.3.3.2 Use Case: Change Accumulation
In the Change Accumulation use case (BAPI method /MSG/BAPI_RIACC_CHANGE), the P2R interface first
determines whether the accumulation from the primary insurance system to be changed is assigned to
reinsurance in Basic System or in Risk Manager.
Objects Created in Basic System
If the accumulation is assigned to reinsurance in Basic System, the accumulation is not changed because no
data is created in the FS-RI system.
Objects Created in Risk Manager
If the accumulation is assigned to reinsurance in Risk Manager, the P2R interface checks whether an
accumulation has already been created with the same ID by the P2R use case Create Accumulation. If it has
not, the P2R interface returns an error message. If the accumulation exists, you can make the following
changes:
● Change general data

● Change existing, general data for the sections
● Change existing liability information
● Change, delete, or reverse existing assignments between sections and an accumulation
● Create new sections for an accumulation
● Create new assignments between sections and an accumulation
 Caution
If imported optional entry fields do not contain any data, the existing values in the FS-RI system are
deleted.
● When the accumulation group is changed, cessions are calculated and confirmed. This does not apply to
accumulation groups for which the Manual Reinsurance checkbox is set.

10.3.3.3 Use Case: Accumulation Information
A calling legacy system can use the Accumulation Information use case (BAPI method /MSG/
BAPI_RIACC_GETDETAIL) to request information for an accumulation in Risk Manager Non-Life on a specific
key date.
In addition to the accumulation data, an overall status for the accumulation and the status for each liability
period are returned to the calling system.
The following fixed values are returned for the status of each liability period.
Status of a Liability Period Status to Be Reported
In force 1
Reversed 2
Unplaced risk requiring facultative cover 3
In process 4
The following fixed values are returned for the overall status of the accumulation.
In force 1
Reversed 2
In process 4
No data for inquiry 5
Messages (table)
Error and success messages are returned using the SAP structure BAPIRET2 provided for BAPIs.
This means that the accumulation information does not use the Postprocessing Office.
Enhancements

10.3.3.4 Use Case: Coverage Check for Accumulation
A calling legacy system can use the Coverage Check for Accumulation use case (BAPI method /MSG/
BAPI_RIACC_CHECKCOVERAGE) to check whether there is sufficient coverage for all the coverages or sections
of a specific accumulation in the FS-RI system. Unlike the “Accumulation Information” use case, where only
data related to a key date is returned, the system returns all the data for the accumulation.
Moreover, the response from the FS-RI system contains the same status data for the liability period and the
entire accumulation as the Accumulation Information use case.
Data is not created or changed in the FS-RI system by the coverage check.
Data Imported or Exported by the Interface
The following fixed values are returned for the status of each liability period.
In force 1
Reversed 2
In process 4
No data for inquiry 5
Messages (table)
This means that the coverage check does not use the Postprocessing Office.
Enhancements
10.3.3.5 Use Case: Create Account
An account is created via the P2R interface in two steps.

Step 1: Creation of a Preliminary Account
In the first step, the system uses the data imported by the BAPI method /MSG/BAPI_RIACT_CREATE to
generate a preliminary account in the FS-RI system.
The system saves denormalized account and posting data in the FS-RI entity PreAccountData. In this step, the
data is saved at section level. No distinction is made here between reinsurance in Basic System and
reinsurance in Risk Manager.
The system saves data that is kept separately in the FS-RI system according to account and posting level
initially in the entity PreAccountData in a table row.
Data is created only for accounts for sections for which reinsurance in Basic System is defined or for sections
with reinsurance in Risk Manager Non-Life, provided the corresponding section exists in Risk Manager. Data is
created for loss accounts only if the loss exists as a preliminary loss or final loss.
Technical Key Management
A GUID is used as the key for saving the data record for a preliminary account in database table /MSG/
8XPREACT. The FS-RI system also stores a time stamp and a sequential number (not a number range object) to
mark the date and time and the sequence of the delivery. The section ID delivered by the legacy system is
saved as an attribute in each account data record.
Step 2: Generation of a Final Account from the Preliminary Account
In the second step, the preliminary accounts are created as final accounts using a downstream background job.
The system removes all successfully created final accounts from database table /MSG/8XPREACT. Preliminary
accounts are not archived and are not assigned to the final accounts.
For more information, see Generation of FS-RI Accounts from Preliminary Accounts [page 605].
Generation of Final Losses from Preliminary Losses
If you create an account as a preliminary account that is assigned to a preliminary loss, the preliminary loss is
created as a final loss (see Use Case: Create Loss [page 608]).
Messages (table)
Enhancements
EXTENSIONIN parameter and by implementing the enhancement spot /MSG/8_PIIX_EXTENSION.

10.3.3.5.1 Generation of FS-RI Accounts from Preliminary
Accounts
Use
The technical name of the background job is /MSG/8_XACT_CRT02_BATCH_PP.
You use this background job to generate final Basic System and Risk Manager accounts from the preliminary
accounts created by the P2R interface.
Prerequisites
● Preliminary accounts have already been created by an interface delivery.

● These preliminary accounts have not already been processed in a previous run of this background job.
● You have made all the technical Customizing settings, the standard Customizing settings, and the
Customizing settings for the interface.
● You have entered all the master data needed to create FS-RI accounts (treaties, accumulations, and so on).
● You have specified in the master data whether parallel accounts are to be created in Basic System for the
assumed Risk Manager Non-Life accounts being created (in Customizing under Default Values for Risk
Manager Default Values for Treaty ).
Features
Differentiation Between Risk Manager and Basic System
Based on the entries in the portfolio treaty [page 586] and on the structure of the preliminary account, the
background job recognizes whether the account is to be created in Risk Manager Non-Life or Basic System and
creates the corresponding Basic System account for the pseudo assumed treaty [page 587] or Risk Manager
account for the section.
Delivery of Account Balances
In Customizing under FS-RI:P2R Interface Mapping Customizing Enter Mapping for Entry Codes , you
can specify for a system and entry code whether postings are delivered in the form of a balance or as delta
postings.
If postings are delivered as a balance, when you run the background job Generation of FS-RI Accounts from
Preliminary Accounts (/MSG/8_XACT_CRT02_BATCH_PP) the system calculates the actual balances for these
target balances in the data posted in the FS-RI system and generates delta postings.
 Caution
Note that because the system needs to calculate the balance it takes more time to operate an interface
with a balance delivery than an interface with a delta delivery.

Further Processing of Accounts
When the background job creates an account in Risk Manager, it also executes the following steps:
● It transfers the account to the ceded business side.

● If you have made the necessary settings in Customizing (see above), it creates a assumed parallel account
in the pseudo assumed treaty in Basic System that illustrates the balance of the assumed business in
relation to treaty sections.
The background job does not process accounts created in Basic System further. Ceded accounts must be
generated using treaty calculation rules or participating treaties.
Summarization
The background job does not generate a final account for each preliminary account but groups postings from
preliminary accounts in a smaller number of final accounts. If there are a large number of preliminary accounts
with the same attributes, this improves transparency in the FS-RI system and system performance.
The minimum number of FS-RI accounts created is restricted by the number of generated packages because
summarization is performed in the program logic after package creation.
Each account is assigned an origin indicator, which references the “P2R interface” as the source. This enables
you to select and analyze these accounts specifically later on.
Parallel Processing
The background job supports the parallel use of background processes to ensure that the preliminary accounts
are processed efficiently.
Error Handling
If one of the objects being processed by the background job causes an error, the system records this error in
the log; the background job is not interrupted.
Logging
The background job creates logs in the SAP Application Log for object /MSG/PII_APPL_ACT.
Creation of External References
You can append the section IDs as external references to the accounts generated by the background job to
make it easier to search for key terms for primary insurance.
 Caution
Note that the number of external references to the summarized accounts also increases if a higher degree
of summarization is used.
Activities
1) Package Creation
1. Start the background job in Schedule Manager using transaction SCMA (task list /MSG/FSRI0) (directly or
scheduled).

2. The background job selects all the unprocessed preliminary accounts and submits these to package
creation during which they are assigned based on their origin (Basic System or Risk Manager Non-Life) to
the processes of the parallel background job.
2a) Processing (Basic System)
1. The background job recognizes that Basic System accounts are to be generated from the preliminary
accounts.
2. The job summarizes the selected data and enhances this with the data required for generating assumed
Basic System accounts. The correct Basic System or Risk Manager Non-Life accounting function is
assigned.
3. The job generates external references for the origin of the preliminary accounts.
4. The job standardizes the account data and transfers this together with the external references to the
standard FS-RI BAPI for account creation.
5. The job deletes the preliminary accounts from the entity for preliminary accounts.
6. The job saves the messages for the background run in the application log.
You can process the assumed Basic System accounts further using the standard functions of the Basic System
account.
2b) Processing (Risk Manager)
1. The background job recognizes that Risk Manager accounts are to be generated from the preliminary
accounts.
2. The job summarizes the selected data and enhances this with the data required for generating assumed
Risk Manager Non-Life accounts. The correct Basic System or Risk Manager Non-Life accounting function
is assigned.
3. The job generates external references for the origin of the preliminary accounts.
4. The job generates assumed Risk Manager Non-Life accounts for the corresponding sections.
5. The job executes a transfer to re/retro for all the assumed accounts created and generates summarized
ceded accounts.
6. If it has been activated in Customizing, the system generates summarized parallel accounts for the pseudo
assumed treaty in Basic System. The assignment to the accounts in Risk Manager Non-Life is not saved.
You can process the ceded Risk Manager Non-Life accounts further using the standard functions of the Risk
Manager Non-Life account. The assumed Risk Manager Non-Life accounts remain unchanged.
If parallel accounts have been created in Basic System, you can process these further using the standard
functions of the Basic System account.
10.3.3.6 Use Case: Create Multiple Accounts
You can use the Create Multiple Accounts use case (BAPI method /MSG/BAPI_RIACT_CREATEMULTIPLE) to
create any number of primary insurance accounts as preliminary accounts in the FS-RI system.
The features, import and export parameters, and further processing of preliminary accounts are the same as in
the Create Account [page 603] use case with the exception of account data and customer-specific
enhancement options that must be delivered as a table instead of a structure due to multiple entries.

10.3.3.7 Use Case: Create Loss
A loss is created via the P2R interface in two steps:
● Creation of a preliminary loss

● Generation of the final loss (for relevant postings)
These steps ensure that losses are not created that only relate to non-reinsurance-relevant classes of business.
Creation of a Preliminary Loss
In the first step, the system uses the data imported by the BAPI method /MSG/BAPI_RICLAIM_CREATE to
generate a preliminary loss in the FS-RI system.
The system saves loss information in the FS-RI entity PreClaimData. No distinction is made here between
reinsurance in Basic System and reinsurance in Risk Manager.
The storage of data must match the structure of the data delivered that, if necessary, must be enhanced by
administrative data.
Key Management
A GUID is used as the key for saving the data record of a preliminary loss in database table /MSG/8XPRECLAIM.
The unique loss ID of the delivery primary insurance system is saved as an attribute.
Generation of the Final Loss from the Preliminary Loss
A final loss is generated if the Generation of FS-RI Accounts from Preliminary Accounts background job
generates an account that refers to a loss that does not yet exist as a final loss in FS-RI.
After the final loss has been created, it can be processed further using the standard FS-RI functions.
All successfully created final losses are removed from database table /MSG/8XPRECLAIM. Preliminary losses
are not archived.
A loss reference allows you to group multiple primary insurance losses for a logical loss in the FS-RI system.
The logical losses are used for the non-proportional account.
The system does not support the assignment of preliminary losses and final losses created via the P2R
interface, and treaties, participations, and policies. It is also not possible to create loss events or loss objects.
When you create the FS-RI losses, the loss ID for the delivery system is saved in the FS-RI system at loss
header level as an interface-unique external reference. If loss accounts are delivered, this external reference is
used to determine the internal FS-RI key for the loss for the account. It is also possible to use the loss ID for the
delivery system to search for FS-RI losses.

Messages (table)
Enhancements
10.3.3.8 Use Case: Change Loss
You can use the Change Loss use case (BAPI method /MSG/BAPI_RICLAIM_CHANGE) to make changes to a
specific preliminary loss or loss created via the P2R interface.
You can only change informative loss data that does not effect existing accounts assigned to the loss. To adjust
accounts, the primary insurance system must deliver new adjustment postings.
This BAPI does not support the implicit creation of losses; only the creation of losses is intended for this task.
 Caution
If optional entry fields are delivered without values, the system deletes existing values in the FS-RI system.
Messages (table)
Enhancements

11 Set Company Code
A company code is the smallest organizational unit for which a complete self-contained set of accounts can be
drawn up.
To set your own company code, choose Environment -> Set Company Code. Users can make use of all the
rights assigned to them through the selected company code.
You can copy the current company code setting to your user parameters by choosing Save. The system then
uses this company code by default the next time you log on.

610 PUBLIC Set Company Code
12 Cross Components
Cross components are relevant for both Basic System and Risk Manager, and are therefore described
separately.
12.1 Loss
Use
You can use SAP Reinsurance Management for SAP S/4HANA (FS-RI) to enter and edit losses and to further
process and release related accounts.
1. You can use classical loss processing [page 613].

In this case, the structure of the user interface is much the same as the object hierarchy of a loss in the
system.
2. You can use loss processing [page 655].
This is based on a floorplan for overview pages (OVP) and provides flexible layout options.
Alternatively, you can use corresponding applications in SAP NetWeaver Business Client (NWBC
applications) that are based on Object Instance Floorplan (OIF) and offer a restricted range of functions.
 Tip
We recommend that you process losses using overview pages because the alternative NWBC
applications that use OIF do not support loss accounts for single risks.
Using one of the specialized applications to manage losses instead of simply posting losses in accounts
has the following advantages:
○ You can enter different data about the origin of the loss.
○ You can group losses in loss events and automatically apply loss event limits.
○ You can enter your own LUDs for a loss.
○ You can create FGU accounts and have the system distribute these to the relevant layers in treaties and
Risk Manager participations.
Prerequisites
The following prerequisites apply to all types of loss posting:
● You have entered your entry codes in such a way that they support FGU accounts. You can use the entry
codes defined in delivery Customizing as a model for this.

Cross Components PUBLIC 611
● The treaties or participations that cover the losses have been created in SAP Reinsurance Management for
SAP S/4HANA (FS-RI) and have a status that allows posting.
● All the business partners involved have been created as SAP business partners in the system with the
relevant roles, such as “Reinsurer” or “Cedent”.
 Note
The use of both the classical SAP application and the NWBC application can lead to inconsistent data.
Once you have edited losses and loss groups with the new applications you cannot continue processing
them with the older applications. You have to define which application you want to use to edit losses.
Features
SAP Reinsurance Management for SAP S/4HANA supports you in the management of single losses and loss
groups.
Loss processing comprises the following steps. The process flow is described in the following sections:
● Single Loss Management [page 612]

● Loss Group Management [page 679]
12.1.1 Single Loss Management
Use
You can use single loss management to edit losses and create accounts for these.
Features
1. You can use classical loss processing [page 613].

2. You can use loss processing [page 655].
Alternatively, you can process losses with Object Floorplan Instance (OIF) [page 672].

612 PUBLIC Cross Components
12.1.1.1 Classical Loss Processing
Use
You can use the Loss Management interface to enter and edit losses and to further process and release related
accounts.
Prerequisites
For more information, see Loss [page 611].
Features
Classical loss processing comprises the following steps. The process flow is described in the following sections:
● General Information [page 613]

● Entering and Editing Losses [page 656]
● Displaying Losses [page 651]
● Copying Losses [page 653]
● Loss Log [page 653]
12.1.1.1.1 General Information
Classical loss processing comprises four levels:
● Access level
● Loss level
● Cedent level
● Treaty and policy level
Structure of the User Interface
To ensure a consistent appearance the user interface is structured in the same way for all FS-RI processes:
● The system displays a description of the current process in the title bar.
● The toolbar is located below the title bar. Depending on the process, the pushbuttons on the left side of the
toolbar provide different functions that you can use to control the process flow.
● Data that belongs together is grouped on “tab pages”. Some tab pages are also subdivided into “group
boxes” in order to structure the data more clearly.

● The system displays messages in the message bar.
Navigation
● You can branch from the initial screen to the loss overview and to loss processing.
● You can switch between the loss overview and loss processing.
● You can navigate from the Cedents tab page in loss processing to the cedent assignments at cedent level.
● You can navigate from the Treaty tab page to the treaty assignments at treaty and policy level.
● You can navigate from the Policy/Certificate tab page to the policy assignments at treaty and policy level.
● You can also choose the Overview pushbutton to navigate to the loss overview without having to enter a
loss number.
Functions to Control Processes
● Change <-> Display: You can switch between change and display mode.
● Cancel: The system cancels the current process and returns to the parent screen.
● Save: The system saves the current status of your work.
● Back: You return to the parent screen.
● Overview: The “Account Totals” tab page appears on which you can display the loss postings and loss
assignments.
● Statistics: You can call the program for reinsurance statistics.
● Log: The system calls the program for the loss log. It displays the entry only if you have activated the log
function in Customizing.
● History: You can view the history of the data displayed on the current tab page.
● Update Display: You can update the current status of your work.
● Undo Incorrect Change: You can reject changes.
● Processing: The Loss Processing tab page appears.
● Extended Search: You can enter additional criteria to search for a loss.
● First/Previous/Next/Last Page: You can switch between different pages.
12.1.1.1.2 Entering and Editing Losses (Classical)
Use
In classical loss processing you can enter the following groups of data:
● Origin of the loss

● Assigned loss event
● Cedents who report receivables from the loss

● Treaties and RM participations that cover the loss
Prerequisites
● You have defined the objects that you want to assign.

● You have defined the loss event that you want to assign.
Activities
Enter Loss
1. Start transaction /MSG/R_U1 (Create Loss).

2. Choose the Create pushbutton.
3. The Create New Loss <>: Loss Processing screen appears.
You can enter data about the origin of the loss on the following tab pages:
○ Loss Processing
○ Cedents
○ Account
○ Individual Loss Assignment
○ Additional Data
○ Extension Service
○ Loss Objects
○ Account Totals
○ Original Policy/Policy Section
○ Accumulation Group
4. Enter data about the origin of the loss (date/time, region, and so on).
5. Optional: Enter a loss event and assign the loss to this event.
6. Assign to the loss the cedent or cedents who are making a claim for payment as a result of the loss.
7. Assign to the loss the treaties and Risk Manager participations in which these claims are defined.
8. When your entries and assignments are completed, you create accounts for the loss.
9. If you are not expecting any more accounts, close the loss.
Result
The loss accounts are calculated and released in the connected current account system.
Initial Screen
The initial screen comprises the following:
● The Loss input field: you can enter a loss number here.
● The Basic Data and Extension Service screen area: you can fill certain selection fields here.
● The Search Result: Loss screen area: the system lists the search results here.
When you choose the Create pushbutton, the system opens the Loss Processing tab page in change mode. In
this case, the system automatically assigns a loss number (internal number assignment).

Alternatively, you can enter your own loss number and then choose the Create pushbutton (external number
assignment). Provided this number has not already been assigned to a loss, the system opens the “Loss
Processing” tab page.
Searching for Losses
Additional Settings for Standard Search
In addition to the standard search using the parameters entered on the Basic Data tab page, you can configure
the search for losses in Customizing as follows:
● Search for losses with an assigned loss object whose name matches the specified policyholder
● Search for losses that are assigned a policy/certificate with a policyholder whose name matches the
specified policyholder
If you have defined Extension Service categories in Customizing, you can enter an Extension Service category
when you search for losses. In this case, the system displays the fields of the specified category on the
“Extension Service” tab page. You can use these to further restrict the search results.
Enhanced Search
In addition to the standard search, you can start an extended search by choosing the Extended Search
pushbutton.
You can enter additional selection options and selection operators.
You can save and check the selection criteria as a variant.
Search Results
The system displays the search results in a table below the tab pages. You can edit or display the losses
depending on the current mode.
The Extension Service fields of customer-specific loss extension tables are also displayed here. In Customizing
for the Extension Service, you can specify which fields are displayed.
If you want to shorten the wait time during a search, you can define the maximum number of hits to be
displayed by the system in a field below the table. The default settings is 200 hits. If you do not make an entry in
the Restrict Number field, the system runs the standard search for all existing data.
You can select a loss by entering a loss number and choosing the Processing or Overview pushbutton in the
toolbar or by choosing the Choose Row pushbutton in the table toolbar.
You can also select one or more losses (multiple processing) in the results table and choose the Processing or
Overview pushbutton.
You can delete one or more losses by selecting the corresponding losses in the results table and choosing the
Delete pushbutton in the table toolbar.
12.1.1.1.2.1 Loss Processing (Classical)
On this screen you can edit loss data, such as duration, classification, location, and amounts, and define
assignments to a loss.

This screen contains the following tab pages:
● Loss Processing
● Cedents
● Account
● Account Totals
● Individual Loss Assignment
● Loss Objects
● Additional Data
● Extension Service
The system displays the loss number of the current loss in the header area of the screen. You can enter the loss
name, loss status, and the reason for change here and you can set the Loss Event checkbox.
Single Loss/Loss Event
If the cause of the loss affects only one risk, the loss is regarded as a single loss.
If the cause of the loss affects several risks, the loss is regarded as a loss event.
You can assign single losses to a loss event. The system displays the Individual Loss Assignment tab page for
loss events.
Propagate Status
The system “closes” a loss by setting a status with the category “Completed”. The system can close a loss only
if all the cedent assignments and their treaty and policy assignments have been closed.
You can set the “Propagate Downwards” checkbox in Customizing. This means that when you close the loss the
system issues a dialog query and then automatically closes all open assignments, provided the integrity of the
data is not harmed.
Clear Loss Reserves
A loss can be “closed” only if all the loss reserves have been cleared.
Depending on the Customizing settings, when you close the loss the loss reserves must have already been
cleared manually or by the system after a dialog query.
You can enter a financial accounting date in the dialog query before the system clears the loss reserves. The
system clears the loss reserves by generating and releasing offsetting entries with the same amounts as the
loss reserves, but with the opposite plus/minus sign.

12.1.1.1.2.2 Assigning Cedents
On the Cedents tab page, you can assign business partners in the role of “Cedent” to the current loss in a table.
When you create a new loss, the system enters the owner company as the cedent in the table by default. You
cannot delete this entry.
You cannot assign a cedent to a loss event (the Loss Event checkbox is set). If the current loss is a loss event,
the system displays all the cedents for the assigned single losses in the table by default. In the case of a loss
event, you cannot assign any other cedents in addition to the owner company.
Navigation
If you double-click the Cedent field in the table the system opens the selected business partner in the business
partner module (FS-BP).
If you select a row on the Cedents tab page and choose the Choose Row pushbutton below the table, the
system navigates to the “cedent level” where you can generate a loss account for the selected cedent.
Propagate Status
A cedent assignment can be “Open” (the status does not have the category “Completed”) only if the current
loss is also open.
The system “closes” a cedent assignment by setting a status with the category “Completed”. The system can
close a cedent assignment only if all its treaty and policy assignments have been closed.
In Customizing you can define which elements you want the system to close at the same time that it closes a
cedent assignment:
● If you set the “Propagate Downwards” checkbox in Customizing, when it closes the cedent assignment the
system issues a dialog query and then automatically closes all open treaty and policy assignments,
provided the integrity of the data is not harmed.
● If you set the “Propagate Upwards” checkbox in Customizing, the system automatically closes the current
loss when you close a cedent assignment (following a dialog query).
Clear Loss Reserves
A cedent assignment can be “closed” only if all the loss reserves have been cleared.
Depending on the Customizing settings, when you close an assignment the loss reserves must have already
been cleared manually or by the system after a dialog query. You can enter a financial accounting date in the
dialog query before the system clears the loss reserves. The system clears the loss reserves by generating and
releasing offsetting entries with the same amounts as the loss reserves, but with the opposite plus/minus sign.

Notes
The Note checkbox in the table on the Cedents tab page indicates whether a note has been created for the
cedent assignment.
To create, change, or display a note for a cedent, select the row that contains the cedent and choose the Note
pushbutton below the table.
12.1.1.1.2.3 Assigning Loss Objects
On the Loss Objects tab page you can assign objects belonging to different categories (for example,
policyholder, building) to the current loss in a table.
If the current loss is a loss event, the system also displays all the loss objects for the assigned single losses in
the table.
Navigation
You can double-click the object number to view it in display mode.
Notes
The Note checkbox in the table on the Loss Objects tab page indicates whether a note has been created for the
loss object.
To create, change, or display a note for a loss object, select the row that contains the loss object and choose
the Note pushbutton below the table.
12.1.1.1.2.4 Assigning Treaties at Cedent Level
Use
To create accounts from the ground up (FGU) for a loss, you must assign the covered treaties and Risk
Manager participations to the loss.
You cannot assign treaties or Risk Manager participations to loss events.

Features
Automatic Assignment
If you created the cedent and also an account for the loss, the system can search for and assign the treaty
section that covers this account.
Otherwise, you have to make this assignment manually.
Manual Assignment
On the Cedents tab page in loss processing, select the row that contains the cedent to which you want to assign
the treaty and choose the Choose Row pushbutton. The system opens the Treaty tab page at cedent level.
When you select a row in the table on this tab page and choose the Choose Row pushbutton, the system
navigates to the detailed level of this treaty (treaty level). You can run accounting functions on the Treaty
Figures and Reinstatement Premiums tab pages.
If you have made the assignment explicitly to a treaty section and a start date, you can also enter loss-specific
LUDs on the Alternative LUD tab page. The other tab pages display the treaty data and loss postings for this
treaty. Additional data is displayed if you have made the assignment to a treaty section and have entered a
start date.
Multiple Processing
If you select more than one treaty in the table on the Treaty tab page at cedent level and choose the Choose
Row pushbutton to edit these, you can navigate in the detailed treaty view between the different treaties for the
current cedent using the “Next Treaty” or “Previous Treaty” pushbuttons.
Status Management
A treaty section assigned to a loss is an entity that has its own status. The following applies to this status:
● An assigned treaty section can only be “Open” (the status does not have the category “Competed”) if the
current cedent, and therefore the current loss, are also open.
● If the “Propagate Upwards (Prop. Up)” checkbox has been set in Customizing for FS-RI Reinsurance under
Basic System Loss Edit Loss Statuses , the system opens the current cedent and loss when you
open a treaty assignment (following a dialog query).
For more information, see Closing Losses [page 648].
12.1.1.1.2.5 Defining Loss-Specific LUDs
Context
If the LUDs for a loss differ from those for the assigned treaty, you can override these by entering alternative
LUDs in the loss.

Procedure
1. At the treaty level of the loss, switch to the Alternative LUD tab page.
2. In the LUD Category column, select the LUDs for the assigned treaty that you want to override for the loss
in question.
3. In the Payment Limit, Reserve Amount, and Alternative Indexation Method columns, enter the valid data for
the loss.
Results
The system uses the values given as alternatives when it processes the account for the loss.
12.1.1.1.2.6 Assigning Risk Manager Participations
Use
You use the loss transaction in Basic System to enter losses covered by an original policy in Risk Manager. From
here, you can also assign the loss you have entered to a participation entered in Risk Manager (Risk Manager
participation) (see Entering Participations [page 622]). This assignment is important for the following reasons:
● The system can check the validity of accounts and postings relating to a loss.
● You can define the process for FGU distribution when a cedent settles the loss. For more information, see
Distribution of FGU Accounts [page 642].
For more information about assigning the participation to the loss, see Loss Assignments (Classical) [page
624].
Integration
You must assign the participations to the loss to enable distribution of the gross loss amounts to the partners
involved. For more information, see Distribution of FGU Accounts [page 642].
In Customizing for FS-RI: Reinsurance under FS-RI: Risk Manager (Non-Life) Default Values Edit Defaults
for Accounting , you define the type of coverage check in the Soft Link field.
Prerequisites
The main prerequisites for assigning losses to participations are as follows:
● The correct roles must have been assigned to the business partner.

● The participation must have already been created in Risk Manager.
The following prerequisite applies for deleting assignments:
● No accounts have been created for the assignment to be deleted.
Features
The assignment of the participation to the loss comprises the following steps:
● Entering Participations [page 622]

● Assigning Participations in the Loss System [page 623]
● Loss Assignments (Classical) [page 624]
● Assigning Cedents in the Loss System [page 625]
12.1.1.1.2.6.1 Entering Participations
1. You enter the Risk Manager participations in the loss at cedent level on the Participation tab page.
2. You enter each Risk Manager participation in a row in the table.
Checking the Participations
The system runs the following checks for the assigned participations:
1. It checks whether the structural characteristics of the loss are covered by the participations.
○ The area covered must be defined in the participation and must not be excluded.
○ The peril must be defined in the participation and must not be excluded.
○ The loss currency and exchange rate type must be defined in the currency settings for the
participation and must not be excluded.
2. It checks the periods covered.
It compares the loss periods against the participation periods, based on the insurance trigger specified in
the participation header (claims made, occurrence). In Customizing for FS-RI: Reinsurance under Basic
System Treaty Edit Settings for Validity Period for Loss Coverage , you can specify which data about
the “sunrise/sunset” and “retroactive date/extended reporting period” is included.
3. It checks the underwriting date.
○ If you assign a participation in underwriting year mode, the system checks that an underwriting date
has been entered for this assignment.
○ The underwriting date entered must match an underwriting date in the participation.
4. It checks accounts and postings relating to a loss.
○ The loss must have the status “Open” (and allow posting).
○ If the Assgmt Check checkbox has been set in Customizing for FS-RI Reinsurance under Basic
System Default Values Edit Defaults for Accounting , a loss can be used in an account or posting
only if it has been assigned to the relevant participation, to a directly preceding share (foreign key of

the account or posting), or to a preceding participation determined recursively. The status of the
assignment that is “closest” to the participation for posting must have the attribute “Posting Allowed”.
 Example
There is an original policy with a policy section. The policy section is assigned to the participation
“CED1” (cedent), which is in turn assigned to the participations “OS1” and “OS2” (our share). The
losses "LOSS1", "LOSS2", and "LOSS3" are assigned as follows:
○ LOSS1 to cedent participation CED1 with the underwriting date January 1, 2003
○ LOSS2 to participation OS1 with the underwriting date January 1, 2003
○ LOSS3 to participation OS2 with the underwriting date January 1, 2004
LOSS1 and LOSS2 can be posted in the participation OS1 with the underwriting date January 1, 2003.
For other underwriting dates, the system displays an error message stating that the loss has not been
assigned.
For LOSS1, the system searches for the assignment backwards using the other share (CED1). Since the
loss has been assigned at this level, it is assumed to be valid for the follow-on participation OS1.
LOSS3 cannot be posted in OS1 since it has neither been assigned to OS1 nor to the cedent
participation CED1. This loss must be posted in the participation OS2.
You can also post LOSS1 in the participation OS2 with the underwriting date January 1, 2003.
5. Other checks:
○ Each rank must be unique for a given company code and assigned participation.
○ The system checks whether the company code of the loss matches the company code of the assigned
participation. The system does not run this check if you have activated cross-company code
processing in internal Customizing for FS-RI Reinsurance under General Settings Edit Chain of
Company Codes .
○ The system checks that only existing participations have been assigned.
○ The status of the loss assigned must not be a copy status and the participation status must be valid
(not “Reversed”).
○ If the same participation is assigned to a loss more than once, each assignment must be for a different
date.
○ You can assign only participations for which the cedent is the same as the selected cedent in the loss.
○ The cedent specified in the assignment must not be locked.
12.1.1.1.2.6.2 Assigning Participations in the Loss System
In Basic System, you assign the participations that carry the liability to the loss. You make the assignments as
follows:
1. In the table on the Cedents tab page, select the row containing the cedent for which you want to enter a
participation or participations. Choose the Choose Row pushbutton below the table.
2. On the next screen, switch to the Participation tab page.
3. Enter the values for the participation in the first available table rows (the fields that are ready for input).
The relevant table columns for Risk Manager are:
○ Participation (number of the participation in the policy)

○ Assignment Date (date for which the loss is formally assigned)
○ Underwriting Date (optional; but must always be entered in underwriting year mode)
○ Rank (must be unique, but is currently not relevant for Risk Manager)
○ Status (see input help)
5. Enter any additional participations.
Deleting the Participation Assignment in the Loss System
You delete a participation assignment as follows:
1. In the table on the Cedents tab page, select the row containing the cedent for which you want to delete the
participation. Choose the Choose Row pushbutton.
2. On the next screen, switch to the Participation tab page.
3. Select the row in the table that contains the participation to be deleted and choose the Delete Row
pushbutton below the table.
4. Choose Save.
If an error occurs, the system displays the following error: “Cannot delete; postings exist for participation
<number of participation>”. In this case, the participation assignment is not deleted.
12.1.1.1.2.6.3 Loss Assignments (Classical)
The FGU distribution function assumes that the loss is posted to the cedent as an FGU account and then
distributed to one or more participations. The relevant participations can depend on the loss and are not
defined in one or several fixed groups as they are for the Transfer to Re/Retrocession function. Instead, you
create loss assignments for the cedent company in the loss transaction.
Loss assignments that you create for assumed or ceded participations for a cedent are relevant only for the
accounts and postings you enter in the loss transaction. These assignments and validation checks are not
relevant for loss postings you enter in Risk Manager on the SAP Easy Access screen under FS-RI:
Reinsurance Risk Manager RM Account .
 Note
To support the processing of losses, you can assign an original policy and policy section or accumulation
group to a loss. This assignment does not have any functional effect.
To enter the assignments, switch to the Original Policy/Policy Section or Accumulation Group tab page at
the top dialog level for the loss. Enter the numbers of the original policy and original policy section in the
table. You need to be careful when you enter the data because the system does not check the consistency
of the entries. You can remove the assignment by choosing the Delete Row pushbutton.

Changing and Deleting Participation Assignments
If you make changes to other data that affects the participation assignment, but not to the assignment itself,
you must make the corresponding changes in the participation assignment manually.
You can delete a participation assignment.
Status Management
A Risk Manager participation assigned to a loss is an entity that can have its own status. The following applies
to this status:
● An assigned Risk Manager participation can be “Open” (the status does not have the category
“Competed”) only if the current cedent, and therefore the current loss, are also open.
● If you have set the “Propagate Upwards” checkbox in Customizing for Basic System under Loss Edit
Loss Statuses , the system opens the current cedent and the current loss when you open a cedent
assignment (following a dialog query).
12.1.1.1.2.6.4 Assigning Cedents in the Loss System
You assign the cedent participating in the policy section group or cession group to the loss.
 Note
If the cedent has already been assigned, you can skip the following steps.
You make the assignment in Basic System:
1. On the SAP Easy Access screen, choose FS-RI: Reinsurance Basic System Loss Change Loss .
2. On the Change Loss: Selection screen, enter the loss number and choose Enter.
3. The Change Loss: Loss Processing screen appears. Switch to the Cedents tab page.
4. The Change Loss: Cedents screen appears. Enter the company number of the partner to which you want to
assign the loss in the first available column in the table (Cedent).
5. Enter a value in the Status column. If you leave this field blank, the system enters the default value “Open”.
6. Choose Enter and save your entries.
12.1.1.1.2.7 Use Basic System to Create Accounts for Losses
Use
You can use this function to create postings for losses. The system generates accounts for these postings and
automatically distributes the postings to the relevant cedents and treaty sections.

Integration
The system creates inward accounts for the cedents participating in the loss; you can see the origin of these
accounts in the account assignment.
Prerequisites
You are authorized to create accounts in Basic System.
Features
The process comprises the following steps and the process flow is described in the following sections:
● Creating Postings [page 626]

● Assignment of a Treaty Section to a Loss Account [page 627]
● Determination of the LUDs to Be Used (Basic System) [page 628]
● Evaluation of Existing Accounts [page 630]
● Splitting Accounts [page 633]
● Calculating Accounts [page 634]
● Release of an Account [page 634]
You can reverse an account using the Reverse [page 635] function. You can also delete individual loss postings
[page 637].
It is also possible to lock [page 636] the loss payments to cedents in the FS-CD system and to remove [page
637] these locks.
12.1.1.1.2.7.1 Creating Postings
Use
To start the accounting process you have to create postings for losses in Basic System. The system generates
accounts for these postings and automatically distributes the postings to the relevant cedents.
Prerequisites
● You have entered one or more losses.

● You have assigned cedents to the losses and entered their participations on the Cedents tab page.

Procedure
You create postings as follows:
1. Switch to the Accounts tab page and switch to change mode if necessary.
2. Create each posting in a separate row in the table and enter all the required inward posting data.
3. Choose Save.
4. The system generates accounts containing these postings and assigns a number that is displayed in the
Account column.
In doing so, it assigns postings with a similar structure to the same account. The status of the generated
accounts is “FGU Pending”.
5. If you want the system to distribute these accounts to cedents, choose the Calculate Loss pushbutton. The
system performs a market loss distribution and distributes the postings in the loss accounts to new
accounts for each cedent. The original loss accounts are given the status “FGU Distributed”. The generated
accounts are given the status “FGU Pending”.
 Note
You can change posting data only if the status of the account is not “FGU Distributed”.
You can delete an account or posting only if the status of the account is “FGU Pending”.
The system displays general FGU accounts on the Account tab page and on the RM Account tab page. You
can reverse these FGU accounts.
Result
The system has created the accounts for the loss that are needed by Basic System for further processing.
12.1.1.1.2.7.2 Assignment of a Treaty Section to a Loss

Account
Use
You can use this function to determine the covering treaty sections for one or more accounts for the cedent
and assign them to the loss or cedent automatically.
Prerequisites
● You have a loss with an assigned cedent and loss accounts (as described in Creating Postings [page 626]).
● A portfolio treaty for Basic System is assigned to the cedent. The Use in RM checkbox must not be set.

● A reinsurance program defined for Basic System exists for this portfolio treaty.
Process
The automatic assignment of treaty sections to loss accounts functions as follows:
You trigger the automatic assignment:
Alternative 1:
1. Switch to the Cedents tab page and select a row in the table.
2. Choose the Choose Row pushbutton in the toolbar below the table. The system navigates to the cedent
level of the loss.
3. Switch to the Accounts tab page and select a row in the table.
4. Choose the Covering Treaties pushbutton in the toolbar.
Alternative 2: Run the Generate Loss Event [page 526] report in Schedule Manager (transaction SCMA).
1. Repeat step 1 for each account to which you want to assign treaty sections.
2. The system performs the following steps in sequence for each of the selected accounts:
○ It checks whether treaty sections have already been assigned to the loss. If they have, it cancels the
function.
○ It runs through the portfolio treaties defined for the cedent that are not marked as Use in RM in
sequence until it finds a portfolio treaty whose structural characteristics match the processed
account.
○ It checks the treaties assigned to the reinsurance program in the portfolio treaty section to determine
whether their structural characteristics correspond to the accounts selected in the loss. If they do, it
assigns the relevant treaty section to the loss at cedent level.
The system does not check the periods as these are determined dynamically for each treaty to include
the rules applying to claims made, sunrise and sunset.
○ If the system finds a portfolio treaty that permits the assignment of treaty sections, it terminates the
function.
○ The system displays the assigned treaty sections on the Treaty tab page. You can edit the entries in the
table to make any necessary changes.
○ Choose Save to accept the changes.
12.1.1.1.2.7.3 Determination of the LUDs to Be Used (Basic

System)
Use
Before the system can distribute a loss posting from the ground up (FGU), it must determine which limits,
underlyings, and deductibles (LUD) are to be used.

Prerequisites
A treaty section or Risk Manager participation has been assigned to the loss.
Features
You can enter different LUDs for each area, peril, currency, loss class, and accounting unit in the treaty section
or Risk Manager participation.
In the loss, you enter the area, peril, and currency at cedent level using the section or participation (Treaty or
Participation tab page); you enter the loss class in the header data for the loss.
 Note
If you have already entered the area, peril, and currency in the header data for the loss, these entries are
used as the default entries at assignment level. However, you can change these entries at assignment level.
You enter the accounting unit in the loss posting.
You can also define alternative LUDs [page 620] for the treaty section assigned to the loss. If you do not enter
any alternative LUDs, the loss management function uses the information entered to determine which area,
peril, currency, loss class, and accounting unit apply to the loss. It selects the corresponding LUDs to be used
to distribute the loss postings to the different layers.
Display of LUDs
When you double-click the treaty number in the table on the Treaty tab page (cedent level), the system
navigates to the header data of the treaty. On the LUD tab page the system displays the loss-relevant LUDs for
the current treaty section in a table (only those that the system has found that can be used).
Activities
If you have not entered any alternative LUDs [page 620] for the treaty section assigned to the loss, the system
determines which LUDs match the data entered (see “Function”) as follows:
● It selects all the LUDs for the treaty section or from the Risk Manager participation and the corresponding
period (initial quantity X).
● From this initial quantity X, it deletes all LUDs for which an area, peril, currency, loss class, or accounting
unit has been entered but that are not supersets of the search data (hierarchy explosion).
● It divides the remaining LUDs according to LUD categories (quantity X1 to XN, where N is the number of
LUD categories found).
● It executes the following steps for each LUD category n = {1; …; N} in the specified sequence:
● If the quantity Xn contains an LUD with a specified accounting unit, it deletes any LUDs without a specified
accounting unit from the quantity Xn.
● If the quantity Xn contains an LUD with a specified loss class, it deletes any LUDs without a specified loss
class from the quantity Xn.

● If the quantity Xn contains an LUD with a specified peril, it deletes any LUDs without a specified peril from
the quantity Xn.
● If the quantity Xn still contains LUDs with different perils, it finds the peril among these different perils that
is closest to the relevant peril in respect of the hierarchy level. It deletes all LUDs containing other perils
from the quantity Xn.
● If the quantity Xn contains an LUD with a specified area, it deletes any LUDs without a specified area from
the quantity Xn.
● If the quantity Xn still contains LUDs with different areas, it finds the area among these different areas that
is closest to the relevant area in respect of the hierarchy level. It deletes all LUDs containing other perils
from the quantity Xn. This means that the system must search through the area hierarchy from the area in
the assigned section upwards.
● If the quantity Xn contains an LUD with a specified currency, it removes any LUDs without a specified
currency from the quantity Xn.
● The system copies the remaining values from Xn to the target quantity Y.
12.1.1.1.2.7.4 Evaluation of Existing Accounts
You can use a number of functions to evaluate the existing accounts for a loss.
An account total is the sum of all postings for a combination of company code, currency, underwriting year,
underwriting date, class of business, line of business, type of business, and loss object.
You can display account totals across losses (in the loss overview) and at loss and cedent level. You can also
edit these totals at loss and cedent level.
Treaty figures [page 631], retrocession figures [page 632], net figures [page 632], and reinstatement
premiums provide you with the account totals of a treaty.
12.1.1.1.2.7.4.1 Account Totals
Use
You can display and edit the account totals for a loss at loss level and at cedent level on the Account Totals tab
page.
Features
Selecting Account Totals

You can use the New Selection pushbutton to reselect the account totals based on the following criteria in the
Selection group box:
● Financial Year: The system displays the account totals with a financial year that is before or the same as the
financial year entered. It also displays the totals of the account postings for loss reserves for the financial
year entered.
● Accounting Year: The system displays the totals for the statistical loss reserves for the accounting year
entered.
● Basic System or Risk Manager (at cedent level only): The system displays either the totals for Basic System
accounts (Accounts tab page) or the totals for Risk Manager accounts (RM Account tab page).
Changing Account Totals
You can enter a new amount for a displayed account total in the “Original Amount” field. The system calculates
the difference between the old and new amount and displays this difference amount. When you save the data,
the system creates a corresponding posting with the amount of the difference.
 Note
In the loss overview, you can display account totals across different losses. However, you cannot edit this
data.
12.1.1.1.2.7.4.2 Treaty Figures
When you select a treaty section (table row) at cedent level and choose the Choose Row pushbutton, the
Change Loss <ID>: Treaty Figures screen appears.
On the Treaty Figures tab page, you can enter or edit accounts or postings (gross figures) for the selected treaty
section in a table, provided you are authorized to create accounts.
When you choose Save, the system assigns postings with a similar structure to the same account. New
accounts are given the status “Pending”.
 Note
Once you have saved account data, you cannot change it. You can only change posting data if the status of
the account is not “Released” or “Distributed”.
You can delete an account or posting if the status of the account is “Pending”, “To Be Released”, or “To Be
Split”.
You cannot edit or delete an account or posting if another user is editing it. In this case, the system locks all the
input fields for the related posting data and displays a corresponding error message.
Navigation
You can double-click a number in the Account column to view the selected account in display mode.

The functions available for editing accounts are also used in the Basic System accounting module. To call one
of the accounting functions, select the account and then choose the corresponding pushbutton:
● Split [page 633]

● Calculate [page 634]
● Release [page 634]
● Reverse [page 635]
12.1.1.1.2.7.4.3 Retrocession Figures
When you select a treaty section (table row) at cedent level and choose the Choose Row pushbutton, the
Change Loss <ID>: Treaty Figures screen appears. From here you can switch to the Retrocession Figures tab
page.
The system displays the retrocession accounts or postings (retrocession figures) for the selected treaty
section on this tab page.
 Note
The retrocession figures are created by distributing the gross figures for the treaty section to the
participating retrocession treaties (using the Split Account function or by running the Process Retrocession
Accounts background job).
The account and posting data is displayed according to the account status, financial year, and entry code of the
retrocession figures:
● The system includes only accounts with the status “Pending”, “To Be Released”, or “Released”.
● The system displays only financial loss reserves that have the same financial year as the latest financial or
accounting year containing posted data.
● The system displays only statistical loss reserves that have the same accounting year as the latest financial
or accounting year containing posted data.
● The system does not include any postings with deductible and limit entry codes.
12.1.1.1.2.7.4.4 Net Figures
On the Net Figures tab page at cedent level the system displays the net figures for the current cedent.
 Note
The net figures are calculated by deducting from the treaty figures the retrocession figures for the treaty
sections that are assigned to the selected cedent (net = gross retro).
Net figures are calculated as follows according to the account status, financial year, and entry code of the
treaty and retrocession figures:

● The system includes only accounts with the status “Pending”, “To Be Released”, or “Released”.
● The system displays only financial loss reserves that have the same financial year as the latest financial or
accounting year containing posted data.
● The system displays only statistical loss reserves that have the same accounting year as the latest financial
or accounting year containing posted data.
● The system does not include any postings with deductible and limit entry codes.
12.1.1.1.2.7.5 Splitting Accounts
Use
You use this function to create individual accounts for the involvements for a treaty from an overall account for
a treaty.
Features
This function creates individual accounts for the individual involvements from an overall account (100%
account) for all involvements for the treaty, provided you have not entered a share in the source account.
Whether the system creates an account for an involvement depends on the applicability of the participations
for the involvement (for example, the written line does not apply). The system includes only participations for
RI-related involvements with a signed line > 0, a status that allows posting, and a period of validity that covers
the start of the accounting period for the account.
It also includes result-independent conditions of the category Stop, Filter, or Transfer Posting, with the portfolio
rule accounting time “With Every Account”.
Because the system considers reinsurers only, when it splits accounts for assumed treaties it creates only one
account for the own share. Nevertheless, you can also create an account for a co-reinsurer.
Activities
You can call this function as follows:
● In an account, choose the Split or Split, Calculate pushbuttons.

● In a background job that creates an account, select a target status for the account created that contains
the split.
When it splits an account, the system performs the following:
1. It converts the postings for all involvements relevant to the account according to their signed line
percentages and creates corresponding pending accounts and postings.
2. If an assumed treaty in a different company code participates in a share (only possible in Basic System),
the system creates an account for the company in the company code and also an account for the
participating treaty. The share of the company is entered in the latter, which means that this account is not
split.
3. It calculates the partial accounts in which a share is stored.

4. It creates a 100% account for information purposes.
12.1.1.1.2.7.6 Calculating Accounts
Use
An account can be calculated only if it has the status “Pending” or “Released” and has a share.
Features
When it runs the Calculate function the system uses the result-independent conditions entered in the treaty to
determine the postings to be made (it does not use the Stop, Filter, and Transfer conditions). It also determines
the expected posting condition amounts based on the data entered in the account. The system compares
these to any actual account postings.
If there is a difference, the system adds corresponding adjustment postings to the account. Depending on the
Customizing settings, the system either posts the difference, or reverses the actual amount and posts the
expected amount in full.
12.1.1.1.2.7.7 Release of an Account
Use
When it releases an account, the system copies the postings for the account to the integrated FS-CD current
account system.
Prerequisites
● The account has the status “Pending” or “Released” (all variants).

● You have assigned a partner involved and cedent to the account.
● The treaty period has a status that allows posting.

Features
When it releases an account, the system performs the following actions:
1. It sets the status of the account to “Released”. This means that no further changes can be made to the
account.
2. It runs all the checks relevant for the account and its postings. If a critical error occurs, the account is not
released.
3. It uses the work table for the ledger group [page 555] for the relevant postings to find the corresponding
ledger group (if you have activated the use of a ledger group [page 481]). It then transfers this ledger group
and the posting to the FS-CD system.
4. It creates participating accounts in a different company code if certain treaty scenarios involve postings in
all company codes. For more information, see Accounts for Connecting Treaties [page 200].
5. It creates opening reserves from posted closing reserves, provided you have made this setting in
Customizing for Basic System under Default Values Edit Defaults for Accounting .
6. It fills the statistics tables.
7. It sets retrocession checkboxes for sections containing retrocession data.
8. It runs the limit check (see Check Limits [page 364]), provided you have configured this check in
Customizing for Basic System under Default Values Edit Defaults for Accounting . You can choose the
following settings for this check:
○ Warning If Limit Exceeded
The system displays a warning message if the limit is exceeded. If you are releasing the account from
the screen, you can confirm the warning message or cancel the release. If you are releasing the
account in a background job, the system releases the account and logs the warning message.
○ Error If Limit Exceeded
The system displays an error message if the limit is exceeded. The account cannot be released.
○ No Check
The system does not check the limits when you release the account.
The limit check is not available in any parallel background jobs that release accounts, with the exception of
background job /MSG/R_ABR_BATCH_PP (Split, Calculate, and Release Accounts: Parallel Processing per
Treaty).
12.1.1.1.2.7.8 Reversing Accounts
Use
You use this function to reset an account that has already been released.
Prerequisites
You have released, but not yet reversed, the account.

Activities
1. In the account to be reversed, choose Account Reverse in the menu bar.

2. The system generates a new account that cancels the original account because the amounts have opposite
plus/minus signs. This account is released immediately and cannot be changed.
 Note
In Customizing for Basic System under Defaults Values Edit Defaults for the Reversal Function , you
can deactivate the reversal of reserve postings in an account.
12.1.1.1.2.7.9 Locking of Loss Payments
Use
You use this function to lock the payment of postings already released in the FS-RI system for payments to the
cedents in the FS-CD current account system.
Prerequisites
In Customizing for Basic System under Interfaces FS-CD Interface Maintain Defaults for FS-CD , you
have set the checkbox that controls the payment lock for FS-CD outgoing payments.
Features
When you select one or more cedents on the Cedents tab page in the loss and choose the Lock Documents
pushbutton, the system performs the following actions:
1. It searches in the current account system for payment documents that were generated by the loss in
question and have not yet been paid.
2. It locks these documents by activating the checkbox maintained in Customizing.
3. It records the locking of payments in the loss log.
 Note
Note that the checkbox in the current account system can be deactivated manually or by the system at a
later time. If this occurs, no notification is sent from the current account system to the FS-RI system.

12.1.1.1.2.7.9.1 Removal of Loss Payment Locks
Use
You use this function to release for loss payments locked in the FS-CD current account system.
Prerequisites
In Customizing for Basic System under Interfaces FS-CD Interface Maintain Defaults for FS-CD , you
have set the checkbox that controls the payment lock for FS-CD outgoing payments.
Features
When you select one or more cedents on the Cedents tab page in the loss and choose the Unlock Documents
pushbutton, the system performs the following actions:
1. It searches in the FS-CD system for payment documents that were generated by the loss in question and
have not yet been paid.
2. It unlocks these documents in the current account system by deactivating the checkbox maintained in
Customizing.
3. It records the removal of this lock in the loss log.
 Note
Note that the system does not recognize whether the lock was set using the “Lock Documents” function in
the FS-RI system or elsewhere (for example, if it was set manually in the current account system).
Therefore, it releases all locked payments for the loss.
12.1.1.1.2.7.9.2 Deletion of Loss Postings
When you delete a loss posting in the loss module, the system performs the following actions:
● If the posting is one of a pair of reversal postings, the system deletes the other posting in the pair.
● If the posting was generated by a market loss posting, the system asks whether you want to delete this
market loss posting as well. If you choose "Yes", the system deletes all postings associated with the market
loss. If you choose "No", the system terminates the delete operation. The system also terminates the
delete operation if there are postings for the market loss that have not been reversed.

12.1.1.1.2.8 Use Risk Manager to Create Accounts for Losses
Use
You use this process to enter or calculate postings for losses that are covered by one or more participations in
Risk Manager.
Prerequisites
The covered Risk Manager participations are assigned [page 621] to the loss.
Features
Loss Accounts in Risk Manager
For the most part, you create accounts for losses in Risk Manager as described in the Risk Manager Accounting
Process [page 142].
You can enter accounts for the participations involved and post the loss amounts relating to the respective
participations in these accounts (like for premium postings in a normal Risk Manager account). You can enter a
loss number at posting item level. This procedure (and the follow-on processes for transferring accounts to the
retrocession side and to Basic System) is not specific to losses and is described in the Risk Manager
Accounting Process [page 142].
FGU Accounts
The system also supports an alternative procedure for creating loss accounts for various participations
automatically.
You can enter loss amounts specified by the ceding company in the loss module and distribute them to the
assigned Risk Manager participations. The system distributes the amounts using the proportional or non-
proportional liability data defined in the participations. This function is referred to as an FGU account and exists
in the same form in Basic System.
The FGU account in Risk Manager Non-Life comprises the following functions:
● Assignment of loss to RM participations

● Entry of FGU accounts
● Distribution of FGU accounts (online, or in a background job)
● Reversal of FGU accounts
● Adjustment of existing distributed amounts (in a background job, or as part of automatic adjustments)
The distribution of FGU accounts creates Risk Manager accounts, which you can then process further using the
following functions:
1. Split
2. Transfer to Basic System

3. Transfer to Reinsurance/Retrocession
You can run these functions in the account or loss transaction or in a background job. Since these functions do
not apply only to loss accounts they are not explained further here.
For more information, see the following sections:
● Transfer to Reinsurance/Retrocession [page 159] (background job: Transfer Accounts to Retrocession)

● Transfer to Basic System [page 163] (background job: Transfer Accounts to Basic System)
Additional Functions
If you make changes to participation data that is relevant for accounting and the FGU account has already been
created, the system adjusts these accounts as part of the retrocession adjustment [page 172] when you
confirm the changes to the participation. You can also use a background job to adjust the account.
If you need to adjust the distributed amounts because the loss data or assignments have changed, you can
also use a background job. For more information, see Adjustment of FGU Distributions [page 549].
Constraints
Note the following constraints for FGU accounts:
● You can enter FGU accounts only at the cedent level of a loss and distribute them to assigned
participations. You cannot create postings for the assigned original policies or policy sections directly, or
distribute accounts automatically to these entities (market loss distribution).
● The system supports only one-level FGU distribution. In other words, when you distribute an FGU account,
the amounts are distributed only to the participations assigned to the loss. Further distribution to
participations assigned via groups is not supported by the FGU account function. Instead, you have to use
the Transfer to Reinsurance/Retrocession function or run a background job.
● The system does not support processing based on reference rank. Participations assigned to a loss are
each processed with the reference rank 0, independently of one another.
12.1.1.1.2.8.1 Determination of the LUDs to Be Used (Risk

Manager)
Use
Before the system can distribute a loss posting from the ground up (FGU), it must determine which limits,
underlyings, and deductibles (LUD) are to be used.
Prerequisites
A treaty section or Risk Manager participation has been assigned to the loss.

Features
You can enter different LUDs for each area, peril, currency, loss class, and accounting unit in the treaty section
or Risk Manager participation.
In the loss, you enter the area, peril, and currency at cedent level using the section or participation (Treaty or
Participation tab page); you enter the loss class in the header data for the loss.
 Note
If you have already entered the area, peril, and currency in the header data for the loss, these entries are
used as the default entries at assignment level. However, you can change these entries at assignment level.
You enter the accounting unit in the loss posting.
You can also define alternative LUDs for the treaty section assigned to the loss. If you do not enter any
alternative LUDs, the loss management function uses the information entered to determine which area, peril,
currency, loss class, and accounting unit apply to the loss. It selects the corresponding LUDs to be used to
distribute the loss postings to the different layers.
Display of LUDs
When you double-click the treaty number in the table on the Treaty tab page (cedent level), the system
navigates to the header data of the treaty. On the LUD tab page the system displays the loss-relevant LUDs for
the current treaty section in a table (only those that the system has found that can be used).
Activities
If you have not entered any alternative LUDs for the treaty section assigned to the loss, the system determines
which LUDs match the data entered (see “Function”) as follows:
1. It selects all the LUDs for the treaty section or from the Risk Manager participation and the corresponding
period (initial quantity X).
2. From this initial quantity X, it deletes all LUDs for which an area, peril, currency, loss class, or accounting
unit has been entered but that are not supersets of the search data (hierarchy explosion).
3. It divides the remaining LUDs according to LUD categories (quantity X1 to XN, where N is the number of
LUD categories found).
4. It executes the following steps for each LUD category n = {1; …; N} in the specified sequence:
○ If the quantity Xn contains an LUD with a specified accounting unit, it deletes any LUDs without a
specified accounting unit from the quantity Xn.
○ If the quantity Xn contains an LUD with a specified loss class, it deletes any LUDs without a specified
loss class from the quantity Xn.
○ If the quantity Xn contains an LUD with a specified peril, it deletes any LUDs without a specified peril
○ If the quantity Xn still contains LUDs with different perils, it finds the peril among these different perils
that is closest to the relevant peril in respect of the hierarchy level. It deletes all LUDs containing other
perils from the quantity Xn.
○ If the quantity Xn contains an LUD with a specified area, it deletes any LUDs without a specified area

○ If the quantity Xn still contains LUDs with different areas, it finds the area among these different areas
that is closest to the relevant area in respect of the hierarchy level. It deletes all LUDs containing other
perils from the quantity Xn. This means that the system must search through the area hierarchy from
the area in the assigned section upwards.
○ If the quantity Xn contains an LUD with a specified currency, it removes any LUDs without a specified
currency from the quantity Xn.
○ The system copies the remaining values from Xn to the target quantity Y.
12.1.1.1.2.8.2 FGU Account (Risk Manager)
An FGU account is an account containing the data relating to a loss, whereby the account is not assigned to a
participation or treaty.
You enter the values reported by the cedent for the loss and any other loss-related posting items in the loss
system, as described in the section Entering FGU Accounts for Risk Manager [page 641].
In the loss system you can assign participations in Risk Manager policies to the cedent.
You can then have the system distribute these FGU accounts in the loss system as described in Distribution of
FGU Accounts [page 642]. The system then reassigns the loss postings based on the liability data defined in
the participations (proportional or non-proportional).
12.1.1.1.2.8.2.1 Entering FGU Accounts for Risk Manager
Use
You can use the loss dialog in Basic System to enter, change, and delete FGU accounts for Risk Manager that
contain loss items that you want to calculate “from the ground up” (FGU).
Activities
To enter a new FGU account, proceed as follows:
1. On the SAP Easy Access screen, choose FS-RI: Reinsurance Basic System Loss Change .
4. On the Change Loss: Cedents screen, select the cedent row for which you want to enter an account.
Choose Choose Row.
5. On the next screen (cedent level), switch to the RM Account tab page.
6. Enter the posting data in the first row of the table in the fields that are ready for input.

 Caution
Note that the system displays only loss-related entry codes in the input help for the “Entry Code” field.
If you enter a different value, the system displays an error message.
7. If you want to enter additional postings, move down to the next free row. Enter the amount posted in the
Amount in Original Currency column. When you choose “Enter”, the system copies the contents from the
row above. You can change the entries if necessary.
8. Once you have entered all the loss postings, choose Save. The system groups the postings for an account
and fills the following fields:
○ Account number – the account ID assigned by the system
○ All the missing code names
9. You can enter additional posting items in the table as described in steps 7 and 8. Each time you save your
entries, the system groups the posting items as a separate account with a new account number.
Provided an FGU account does not have an account number, you can still change the related accounts and
postings. Then choose Save.
Provided an FGU account has not yet been distributed and the status is “FGU Pending”, you can still delete the
account. Select the corresponding posting item and choose the Delete Row pushbutton. Then choose Save.
For more information, see Risk Manager Account [page 147].
 Note
The system displays general FGU accounts on the Account tab page and on the RM Account tab page. You
can reverse these FGU accounts.
12.1.1.1.2.8.2.2 Distribution of FGU Accounts
Use
Once you have entered an FGU account, you can have the account distributed automatically to the
participations assigned to the respective loss.
You can distribute FGU loss accounts either in the loss dialog in Basic System or using a background job. This
document explains how you distribute FGU accounts online. For more information about the background job,
see FGU Distribution "FCFS" (Risk Manager) [page 527].
Integration
In Customizing for FS-RI: Reinsurance under FS-RI: Risk Manager (Non-Life) RM Functions Edit Settings
for Checks , you have defined the type of coverage check using the FM Active checkbox. If you set this
checkbox, the system does not distribute the account if one of the participations assigned to the loss cannot
be applied because of different structural characteristics. If you do not set this checkbox, the system applies
the assigned coverages that match (see example 2 below).

Prerequisites
● In Customizing for FS-RI: Reinsurance under FS-RI: Risk Manager (Non-Life) Default Values Edit
Defaults for Accounting , you have defined the type of coverage check using the Soft Link checkbox.
● You have entered participations for the loss.
● There is an FGU account with an open status (such as “FGU Pending”).
Features
When you distribute an FGU account for a loss, the system analyzes the policy participations you assigned to
the loss during the assignment of Risk Manager participations [page 621].
For each posting in the FGU account and for each assigned participation, the system calculates the extent of
the coverage and the assumed liability. It then generates the postings and corresponding accounts
automatically.
The system executes the following steps:
1. It checks the following:

○ It checks whether the status of the loss account is “FGU Pending”.
○ It checks whether the specified object can be assigned to the loss.
○ It checks whether the entry code is permitted.
2. The system reads the participations assigned to the loss.
3. For each posting in the FGU account, the system checks which of the participations cover all the structural
characteristics and (where appropriate) the specified underwriting date. It does not include the other
participations for distribution later on.
If there is no relevant participation for a posting, the system returns a corresponding error message. If you
have not set the FM Active checkbox in Customizing for FS-RI: Reinsurance under FS-RI: Risk Manager
(Non-Life) RM Functions Edit Settings for Checks , the system returns an error the first time the
coverage check for one of the assigned participations fails.
4. The system distributes the loss amounts to the participations assuming the liability. To do so, it creates and
saves corresponding Risk Manager accounts.
5. It assigns the status “FGU Distributed” to the FGU account.
Activities
You can distribute an FGU account with the status “FGU Pending” in the following ways.
Distribution Using a Background Job
You start a background job in Schedule Manager. This allows you to distribute several FGU accounts in one
step. For a description of this procedure, see FGU Distribution "FCFS" (Risk Manager) [page 527].
Distribution in the Loss Dialog

You manually trigger the distribution of an existing loss account in the loss system. To do so, proceed as
follows:
4. On the Change Loss: Cedents screen, select the cedent row for which you want to distribute an account.
Choose Choose Row.
5. On the next screen, switch to the RM Account tab page and select the row containing the FGU account to
be distributed.
6. Choose Calculate Loss.
7. The result of this procedure depends on whether the distribution was successful:
○ If the distribution was successful, the system sets the status of the account to “FGU Distributed”. In
this case, accounts and postings have been generated for the participations that are assigned to and
assume liability for the loss.
○ If the distribution was not successful, the existing FGU accounts remain unchanged. In this case, the
system returns error messages specifying the reason why the distribution failed:
○ The account has already been distributed.
○ There are no participations with matching coverage.
○ There was an error during distribution (error in a Risk Manager policy or in the non-proportional
account).
 Example
Example 1:
There is an original policy with the policy sections 1 and 2.
Policy section 1 is assigned to the participation CED1, which is in turn assigned to the participations OS1
and OS2 (our share).
Policy section 2 is assigned to the participation CED2 (with the same company as CED1), which is assigned
to the participations OS3 and OS4.
A loss is assigned to the participations OS1 and OS4 at cedent levels CED1 and CED2.
You now create an FGU account for the cedent.
During the FGU distribution run, postings are made to participations OS1 and OS4. The amounts posted
depend on the limits and deductibles (LUD) or (for proportional business) quota shares defined for the
participations OS1 and OS4.
The participations OS2 and OS3 are assigned to the cedent via groups, but are not relevant for the FGU
distribution of the loss.
Example 2:
The participations OS1, OS2, and OS3 are assigned to the loss “Fire in Warehouse”.
OS1 covers the class of business “Liability Insurance”, OS2 and OS3 cover the class of business “Business
Interruption”.
You now determine the loss amount for the class of business “Business Interruption” and enter a
corresponding FGU account.

During the distribution run, the system analyzes participations OS2 and OS3 but ignores OS1.
12.1.1.1.2.8.2.3 Adjustment of FGU Distributions
It may be necessary to make an adjustment to FGU accounts for the following reasons:
● The original FGU account was not entered correctly, but has already been distributed. In this case, you
have to reverse the FGU account [page 645] and then enter and distribute a new FGU account.
● The original FGU account was entered correctly and has been distributed. However, the attributes relevant
for accounting were not correct in the loss or participation at the time of distribution.
In this case, the adjustment involves reversing the (incorrect) FGU distribution postings and running the
FGU distribution again for the correct participations. You cannot perform this adjustment in the dialog.
However, it can be performed using the FGU Recalculation Process [page 528] background job. The system
adjusts FGU distributions as part of the retrocession adjustment, which you can start manually from Risk
Manager or as a background job.
12.1.1.1.2.8.2.4 Reversal of FGU Accounts
Use
The purpose of reversing accounts is to reverse the postings belonging to an account and to delete any entries
that have been prepared, but not yet posted.
 Note
If the FGU account still has the status “FGU Pending”, you do not have to run the reversal function. You can
just delete the account in the table in which you entered it.
Prerequisites
There is an FGU account to be reversed with the status “FGU Distributed”.
Features
The reversal function comprises two subfunctions:
1. A new account is created (a reversal account).

○ This new account is assigned a new account number.
○ The account postings are given the opposite plus/minus sign.

2. The reversal account is distributed. For more information about how the account is distributed, see
Distribution of FGU Accounts [page 642].
For more information about the reversal function, see Reversal of Risk Manager Accounts [page 167].
Activities
To reverse an account, proceed as follows:
4. On the Change Loss: Cedents screen, select the cedent row for which you want to distribute an account.
Choose Choose Row.
5. On the next screen, switch to the RM Account tab page and select the row containing the FGU account to
be reversed.
6. Choose the Reverse pushbutton.
7. The system executes the following steps:
○ It generates offsetting postings.
○ It distributes the FGU accounts and generates pending Risk Manager accounts (to be released).
○ It sets the "Reversal" checkbox in the affected FGU accounts.
12.1.1.1.2.9 Parallel Processing of a Loss
Use
A loss can affect more than one cedent and can extend across several company codes. Using the lock concept
in the loss transaction, you can process these losses more efficiently; a loss can be edited by more than one
user in parallel in more than one SAP session.
Prerequisites
In Customizing for FS-RI Reinsurance under Basic System Loss Program Control , you have set the
ParLossPro (parallel loss processing) checkbox.
If you do not set this checkbox, you can open a loss in processing mode only in one SAP session.

Features
During loss processing, the loss concept makes a distinction between loss header level and cedent level. These
levels are handled differently. When you access the loss, you are at header level.
When you select a row on the Cedents tab page and choose the Choose Row pushbutton, the system navigates
to the cedent level. All tab pages at this level and at lower levels are regarded as cedent level by the lock
concept.
Activities
Changing Data at Loss Header Level
The data at loss header level is locked optimistically. This means that the system does not lock data when it is
being read from the database (and not when it is in processing mode) but only locks it briefly when it is being
saved.
You can save any changes made to the data only if any changes made to the data at loss header level have not
been saved since the time of data selection.
When you choose the Refresh Display pushbutton, the system updates the displayed data to the most recently
saved status. You can change and save data until a different user saves their data.
Changing Data at Cedent Level
If you have activated parallel loss processing, you cannot navigate to the cedent level until you have saved your
changes at loss header level.
The following applies to the cedent level:
If the cedent level of a loss is open in processing mode, you cannot open it for processing in a different SAP
session. The system also sets this lock when you run the Calculate Loss, Lock/Unlock Documents, or Delete
Cedent Assignment functions.
You can save any changes made to the data at cedent level provided the data at loss header level has not been
changed or saved by a different user in the meantime.
Changing Data Using SAP NetWeaver Business Client Application
The SAP NetWeaver Business Client application also works with optimistic locks. However, these locks do not
distinguish between loss header and cedent level, but the loss is regarded as a unit: In the NWBC application
several users can open a loss at the same time. However, if a user saves a change to a loss after another user
has opened the loss, the latter user cannot save the loss.
Deleting a Loss
The lock function at loss header level applies when you delete a loss. If this lock function allows changes to be
made to the data, you can delete a loss even if it is being processed by a different user.

12.1.1.1.2.10 Closing Losses
If you want to end or temporarily lock the processing of a loss, a cedent assignment, or a treaty or participation
assignment, you can assign a status to the loss that prevents amounts being posted to it.
Depending on the settings for this status, when the system converts the status it also performs additional
activities related to loss processing. The FS-RI system differentiates between the following cases:
● Locking of a Loss [page 648]

● Closing of a Loss [page 649]
● Declaration of a Loss as Invalid [page 650]
12.1.1.1.2.10.1 Locking of a Loss
Use
When you close a loss, the system does not allow any more postings to be made to this loss. You may need to
lock a loss while you are preparing the loss data or while you are clarifying the reinsurance for a loss, for
example. To lock a loss, you set the loss to the status provided for this purpose (such as “Locked”).
Prerequisites
● In Customizing for FS-RI Reinsurance under Basic System Loss Edit Loss Statuses , you have
defined a loss status for which the Locked checkbox has been set.
● There are only accounts for the loss that have the status “Released”.
Features
When you set a loss to a status that meets the above prerequisites and then save the loss, no further postings
can be made to it.
To unlock a loss, change the status of the loss to a status that allows posting.
For more information about locking loss payments that have already been created, see Locking of Loss
Payments [page 636].

12.1.1.1.2.10.2 Closing of a Loss
Use
When you close a loss or part of a loss, the system writes off any existing loss reserves and sets the closed
entity to a status that does not allow posting.
Prerequisites
defined a loss status for which the Completed checkbox has been set.
The following prerequisites also apply if reserves have to cleared when you close the loss:
● In Customizing for FS-RI Reinsurance under Basic System Loss Program Control , you have defined
a calculation base in the Calc. Base field that contains the entry codes that you want handled as reserves
by the Clear Loss Reserves subfunction.
● In Customizing for FS-RI Reinsurance under Basic System Loss Program Control , you have set the
Clear checkbox and you have defined the level of clearing in the To Level column.
● You are authorized to process loss accounts.
Features
You can close the following levels of a loss:
● The entire loss

● A single cedent assignment with all the treaties or participations for the cedent
● A single assigned Risk Manager participation
● A single assigned treaty
To close one of these entities, set the status of this entity to a status that meets the above prerequisites
and save your entries.
Checking Lower-Level Entities
When you close a higher-level entity for a loss (entire loss or cedent), the system checks whether the lower-
level entities (cedent or treaties or participations) have already been closed. If they have not been closed, you
can choose whether you want to close the lower-level entities or cancel the closing of the loss.
You cannot close a higher-level entity if the lower-level entities are still open.
Clearing Reserves
When you close a loss entity, the system checks whether loss reserves are open for this entity. If this is the
case, you can choose whether you want to cancel the closing of the loss or clear the reserves using offsetting
postings.

The system proceeds as follows:
1. It reads the entry codes from the specified calculation base. If you have not entered a calculation base or
this calculation base is empty, the system accepts all entry codes as valid.
2. It compresses the postings into these entry codes so that the total balances for the postings have the same
structure (company code, treaty section, and so on).
3. It displays the open reserve balances. At this point you can decide whether you want to clear these
reserves or cancel closing of the loss.
4. If you want to continue closing the loss, you can enter an FI accounting date for the offsetting posting in the
next step. This date must lie in a period that allows posting. If you do not enter a date, the system assigns
the first of the following dates to the postings:
○ Latest FI date that allows posting
○ Current date
○ Earliest FI date that allows posting
○ System terminates processing and displays an error message
5. The system creates accounts and offsetting postings for the reserve balances and automatically processes
these new accounts according to the standard process chain. This process chain differs depending on
whether these are Risk Manager or Basic System accounts.
Entering Accounting Period
You can enter an accounting period (client accounting period, CAP) to be used to clear reserves at all levels of
the loss. The following conditions apply:
● The accounting period must be later than or the same as the earliest accounting period for the loss that
contains postings.
● The accounting year must be the same as the earliest accounting year for the loss that contains postings.
If you do not enter an accounting period, the system clears the reserves in the accounting period in which they
were posted.
Reopening Closed Losses
If you want to edit a loss that has already been closed, you have to reset its status to a status that allows
posting. When you do this, the system does not reset the changes made to the accounts during the original
status change.
If errors occur when a loss is closed, the system resets all the changes made, including those made to the
accounts.
12.1.1.1.2.10.3 Declaration of a Loss as Invalid
Use
You set a loss to the status “Invalid” when you want to close a loss to processing and reverse or delete all the
postings for this loss. After postings have been deleted, the system also deletes any accounts that do not
contain any further postings.
You cannot reset the “Invalid” status.

Prerequisites
defined a loss status for which the "Invalid" checkbox has been set.
Activities
When you set the status of the loss to "Invalid" at header level and then save the loss, the system does the
following:
1. It searches for postings for this loss.

2. It reverses split or released accounts with postings for this loss. This does not apply to reserve postings
that do not relate to the current accounting year or the current financial year.
3. It deletes all open accounts with postings for this loss. This does not apply to reserve postings that do not
relate to the current accounting year or the current financial year.
4. It recalculates accounts without the invalid loss and releases these.
12.1.1.1.3 Displaying Losses
Use
You can use this function to check all the data for a loss. More specifically, you can obtain information about the
loss postings and the account totals for the loss.
The account totals display the postings for one or more losses in a total. The system displays the postings
according to the entry code and the status of the related accounts.
 Note
The system does not display postings with limit or deductible entry codes.
The system displays only postings for accounts that have a status that is not “FGU Open”, “FGU
Distributed”, and “Split”.
The system calculates the subtotals for each treaty and loss and the total of all displayed postings and displays
these. The postings for assumed treaties and participations are included as positive figures in these totals, and
the postings for ceded treaties and participations are included as negative figures.

Prerequisites
The system displays loss postings only if the following prerequisites are met:
● The treaty number matches the specified treaty number.

● The section number matches the specified section number.
● The participation number matches one of the participations assigned to the specified policies.
● The participation number matches the specified participation.
If you enter data for several fields, the system shows how this data overlaps.
Activities
1. On the SAP Easy Access screen, choose FS-RI: Reinsurance Basic System Loss Display .
2. The Display Loss: Selection screen appears.
3. If you want to find information for a specific loss, enter a loss number in the Loss field. You can also leave
this field empty if you want to show the data for several losses.
4. Choose the Overview pushbutton in the toolbar.
5. The Display Loss <Loss Number>: Account Totals screen appears in display mode.
If you entered a loss on the initial screen, this screen contains the header data for this loss.
If you branched to the loss overview without selecting a specific loss, the system displays the postings for
all losses that you can restrict using the loss selection fields.
6. The system controls which postings are displayed based on the criteria that you define on the Account
Totals tab page:
○ Display postings by loss category:
○ If the current loss is a single loss, the system displays all postings for this loss. In this case, the
selection fields for losses are not ready for input.
○ If the current loss is a loss event, the system displays the postings for this loss event and its
assigned single losses. You can use the loss selection fields to restrict the display to certain losses.
○ Display postings by financial year - the year entered in the Financial Year field:
○ The system displays loss reserve postings only if the financial year of the related account matches
the financial year entered.
○ It displays all other postings that are not loss reserves if the financial year of the related account is
before or the same as the financial year entered.
○ Display postings by system - the system is specified by radio button in the Accounts group box:
○ All: The system displays all the postings from Basic System and Risk Manager. If you restrict the
display further to a policy or participation, the system displays Risk Manager accounts only.
○ Basic System: The system displays postings that belong to Basic System.
○ Risk Manager: The system displays original postings that belong to Risk Manager.
○ Display main object
○ If you have entered the posting for a participation, the system also displays information about the
main object.
○ The main object for a participation can vary from period to period and is saved in the
corresponding, higher-level group period. In the clearing data you can view which participation
period and group period apply to the posting.

○ The system distinguishes between a main object that is an accumulation and a main object that is
a policy. The data for this policy or accumulation is displayed as well as the data for the main
object category. Therefore, if you restrict the display to a policy you can still display an
accumulation as the main object of the participation.
7. The system displays information about the treaty and policy assignments as well as about the loss
postings and assignments to this loss on the remaining tab pages.
12.1.1.1.4 Copying Losses
Use
You can use this function to copy an existing loss. When you copy a loss you can select which entities are to be
copied to the target loss.
By default, the system always enters the owner company as the cedent in the target loss.
Prerequisites
You are authorized to create a loss.
Activities
1. On the SAP Easy Access screen, choose FS-RI: Reinsurance Basic System Loss Copy .
2. Enter the loss number of the loss that you want to copy (source loss).
3. You can enter a loss number (external number assignment) for the copied loss (target loss).
If you do not enter a loss number, the system assigns a number automatically (internal number
assignment). When it has copied a loss without errors the system displays the number of the target loss in
a message.
4. If you do not enter a name for the target loss, the system creates the name “Copy of <source loss>”.
5. You can use the different checkboxes in the Entities to Copy group box to select the entities of the source
loss that you want to copy.
6. Choose the Execute pushbutton.
12.1.1.1.5 Loss Log
Use
The loss log records the log texts for the loss activities that you create and edit when you manage losses.

A loss can be assigned to one or more cedents and each cedent can be assigned to treaties and policies in
different company codes. To reflect this, each log text is assigned to a combination of loss, cedent, and
company code. This means that each loss can have several logs for different combinations of loss, cedent, and
company code.
Features
The system can generate log texts automatically for specific events. You can activate the automatic logging of a
change to the loss status (including the creation or copying of a loss) in Customizing.
Alternatively, you can create log texts manually.
Program Call
You can start the loss log using the following transactions:
● /MSG/R_U_LOG_CHANGE (Change)
● /MSG/R_U_LOG_DISPLAY (Display)
Alternatively, you can call the loss log from loss management. In this case, the system skips the initial screen
for selecting the loss log, opens the loss log in its own window, and copies the number of the current loss.
List of Log Entries
When you double-click a company code in the navigation tree of the loss structure (on the left side of the
screen), the system lists the related log entries in reverse chronological order in a table (on the right side of the
screen).
The entries contain the category, name, and author of the log text, as well as the date, time, and time zone in
which it was created.
The table offers a range of standard functions for the list of log entries:
● Find
● Print
● Export
● Filter (by category)
● Layout
You can also use the Print Text pushbutton in the table toolbar to print the text of all the selected log entries.
You cannot delete existing log entries from the loss log.
Display Log Text
You can select an item in the list of log entries (by double-clicking any field in the corresponding row) to display
the related log text in the SAPscript editor.
In addition to the other standard functions of the SAP text editor, you can also print out the text.
You cannot change the text that is displayed.
Create Log Text
1. Choose the Create Text pushbutton.

2. Fill the Category, Description, and Language fields.

4. If you confirm the query when you leave the editor, the system saves the new text.
If you cancel the query when you leave the editor, the system terminates the process. You return to the
editor and you can enter a new text.
If you reject the query, the system rejects the text you entered.
If you create a text template for a log category in Customizing, the system uses this formatting for each new
text with the corresponding category.
If you select an existing log entry in the table, the system copies the text and its formatting to the new log text
(copy function) and you can edit this text.
The log text of the selected entry is not changed.
12.1.1.2 Loss Processing
Use
You can use the Loss Processing application with overview pages (OVP) to create, edit, and display losses.
You access the OVP application in SAP NetWeaver Business Client (NWBC) under FS-RI 700_01 Loss
Processing Loss Loss Management .
The application consist of the following main pages:
● Loss [page 656]

● Cedent [page 678]
● Activities [page 661]
● Coverages [page 665]
● Applicable LUDs [page 666]
● FGU [page 662]
● Preview [page 667]
● Evaluations [page 670]
 Note
For more information about the structure of the user interface and the functions for controlling NWBC
applications, see Structure of the User Interface [page 778].
Prerequisites
● Before you can use the SAP NWBC loss applications, you have to activate the corresponding HTTP
services for SAP Reinsurance Management for SAP S/4HANA in parallel to the services for operating SAP
NWBC. You use transaction SICF to do this.
● You have assigned the new applications for loss management to the corresponding PFCG roles.

 Note
For more information about configuring SAP NWBC and the Web Dynpro applications, see Configuring
Web Dynpro Applications and SAP NetWeaver Business Client [page 781].
12.1.1.2.1 Entering and Editing Losses
Procedure
In the Loss Management application you can create a loss using the search screen [page 778] as follows:
1. Start the Loss Management application under FS-RI 700_01 Loss Processing Loss Loss
Management .
2. Under Results List choose the New pushbutton or choose "Create Loss" from the selection list under You
can also in the toolbar.
You create a loss on the main page entitled “Loss”. This comprises the following subpages:
○ Basic Data
○ Objects
○ Groupings
3. The Basic Data page appears. You can enter information for the following areas:
○ Basic Data
○ Time Units
○ Classification
○ Location
○ Amounts
○ Responsibilities [page 294]
○ External References [page 723]
○ Attachments and Notes [page 659]
4. Fill all the required entry fields for basic data, time units, classification, and responsibilities.
5. Choose the Save pushbutton to save your entries.
Default Settings
The following default settings apply when you create a loss:
● Company Code: surrounding company code

● Business Partner Role: You can configure the necessary roles and responsibilities in Customizing in
transaction SPRO under FS-RI Reinsurance Basic System Loss Edit Responsibilities for the Loss .
● Time Zone: surrounding time zone or system time zone
 Note
When you create a loss the system copies the search criteria fields that you entered on the search
page. These can override the defaults settings for the company code and time zone.

Result
You have created the loss and you can edit this as follows:

Objects
If more than one object is affected by the loss you can assign these objects to a loss.
Prerequisites
You can assign to a loss only objects whose area and validity period covers the loss.
Procedure
1. Select a loss from the search screen in the Loss Management application.
2. On the Loss -> Objects page under Object Assignment, choose the New pushbutton.
Alternatively, you can choose the Edit pushbutton.
3. In the Object ID field, enter the corresponding object ID. Alternatively, in the Search:ID dialog box you can
enter different search criteria to find specific objects.
4. Choose the Save pushbutton to save the corresponding object assignment.
Result
You have created the object and you can edit this as follows:
● Under Object Assignment, select the name of the object.

● The Object Management application opens with the Basic Data page. You can edit the object further here.
For more information, see Object Processing [page 42].
Groupings
You can assign a loss to a loss group or group a loss using a loss reference.
Procedure
2. On the Loss -> Groupings page, choose the Edit pushbutton.
3. Under Groupings you can use the input help and different search criteria to find loss groups or loss
references.
Alternatively, you can enter the identification numbers manually.
4. Select a loss group, a loss reference, or both and use the Save pushbutton to confirm the grouping.
 Note
Note that you can assign a loss to a loss group only if this loss group covers the loss period and loss
area.
Result
You have saved the grouping and you can edit the information under Groupings using the Edit pushbutton.
You cannot edit any other sections.

12.1.1.2.1.1 Responsibilities (OVP)
Use
You can create and delete responsibilities. You cannot change responsibilities.
Activities
Creating Responsibilities
1. Under Responsibilities choose the New pushbutton.

2. Fill the required entry fields Business Partner ID/Organizational Unit ID and Business Partner Role /
Competence (if they have not been configured as mandatory roles in Customizing and filled by the
system).
Default Settings
When you create new business partner roles the system enters the responsibilities that have been configured
as mandatory.
 Note
You can configure the roles and responsibilities in Customizing in transaction SPRO under FS-RI
Reinsurance Basic System Loss Edit Responsibilities for the Loss .
You can use either organizational plan or business partner responsibilities.
For additional information, see the corresponding documentation in the system.
Deleting Responsibilities
If you want to delete individual responsibilities, choose the Delete pushbutton in the Actions column.
If you want to delete several responsibilities at the same time, proceed as follows:
1. Select all the rows that you want to remove.

2. Choose the Delete pushbutton in the area toolbar.
3. You can confirm or cancel the deletion in a dialog box.
12.1.1.2.1.2 External References (OVP)
Use
You can create, edit, and delete external references.

Activities
Creating and Editing External References
1. Choose the New pushbutton.

2. Fill the required entry fields External Reference ID and Category of External Reference.
Default Settings
The system enters the owner company in the Business Partner ID field. You can change this default setting
manually.
 Note
You can assign external references that have already been created for one loss to a different loss but only if
the category of the external reference is not unique to the interface or to the object.
Deleting External References
1. If you want to delete individual external references, choose the Delete pushbutton in the Actions column.
2. If you want to delete several external references at the same time, proceed as follows:
○ Select all the rows that you want to remove.
○ Choose the Delete pushbutton in the area toolbar.
○ You can confirm or cancel the deletion in a dialog box.
You can also delete external references that are unique to an interface. A dialog box appears in which you can
confirm or cancel the deletion.
You can use the Business Add-In /MSG/82_UI_EXTREF_BADI to deactivate the deletion of external references
that are unique to interfaces.
For additional information, see the corresponding documentation in the system.
12.1.1.2.1.3 Attachments and Notes
You can do the following in the new Loss Processing application:
● Create, edit, and delete notes

● Add, remove, and download attachments
● Enter additional information in the form of links with valid URL addresses
When you select a link the system opens a new page on which these links can be processed further.
It is not possible to upload empty documents.

12.1.1.2.2 Close Loss
Use
On the Loss Management overview page, you can close a loss for the corresponding level at cedent and
coverage level.
Close Cedent
You choose the Close pushbutton in the corresponding cedent area to navigate to a new dialog box to close the
loss for the corresponding cedent.
You can enter information about the cedent’s status in this dialog box. If reserves are to be cleared, you can
enter information about the new activity to be created and the corresponding accounts.
When you close a cedent, the system clears all the assigned open reserves and sets the status of the cedent
and its coverages to “Completed”.
When you close the last cedent for a loss, the system sets the status of the loss to “Completed”.
Close Coverage
You choose the Close pushbutton in the corresponding coverage area to navigate to a new dialog box to close
the loss for the corresponding coverage.
You can enter information about the coverage’s status in this dialog box. If reserves are to be cleared, you can
enter information about the new activity to be created and the corresponding accounts.
When you close a coverage, the system clears all the assigned open reserves and sets the status of the
coverage to “Closed”.
When you close the last coverage for a cedent, the system also automatically closes the higher-level cedent if
the total balance of open reserves for the cedent is zero. If this is the last open cedent, the system
automatically closes the entire loss.
12.1.1.2.3 Reverse Loss
Use
You can use this function in the loss search area on the Loss Management overview page to reverse a loss
selected from the list of search results by choosing the pushbutton Reverse. The system then sets the loss and
all related cedent and coverage assignments to a reversed/invalid status and reverses all the existing posting
data in the FS-RI system for this loss.

12.1.1.2.4 Activities
Use
The activity bundles all FGU accounts and their derived accounts.
The activity provides an overview of all the amounts reported by a cedent for a loss and helps you to trace the
origin of derived accounts at a later date.
Prerequisites
You have created at least one cedent.
Activities
Creating Activities
You create an activity as follows:
2. On the Activities page, choose the New pushbutton.
3. A page appears on which you can edit the activity.
4. Choose the Save pushbutton to assign the activity to the corresponding loss and cedent.
Default Settings
When you create an activity the system fills the following fields by default:
● Validity Date: current date

● Date of Receipt: current date
● Activity status: “Open”
● Currency: taken from the basic data
Editing Activities
You can edit activities in the following ways:
1. On the Activities main page in the Loss Management application, select the activity ID.
A page appears that contains details of the activity.
You can choose the Edit pushbutton in the respective area to edit the basic data, enter attachments and
notes, and to create and edit external references.
For more information, see External References [page 723] and Attachments and Notes [page 659].
2. On the Activities page in the Loss Management application, choose the Edit pushbutton under Activities.
You remain on the Activities main page but you can edit header data, such as the activity name, validity
date, target balance, and currency.
Deleting Activities
You can delete an open activity provided there are no FGU accounts or local LUDs for this activity.

To delete an activity, choose the Delete pushbutton in the Actions column.
Reversing Activities
Select the corresponding activity on the Activities main page and choose the Reverse pushbutton.
When you reverse an activity the system reverses all the accounts (even FGU accounts) for this activity.
The activity is given the status “Reversed”.
 Note
When you reverse an activity the system does not recalculate the loss automatically. If the activity you are
reversing is not the most current activity or if there are LUDs for the activity that apply to several losses,
create a new activity to recalculate the loss and go directly to the preview to view and finalize the results of
the recalculation.
For more information, see Preview [page 667].
12.1.1.2.5 FGU
Use
In the new Loss Management application, you can enter and edit FGU accounts that the system distributes at
the same time to treaties and Risk Manager participations.
Constraints
Note the following constraints:
● You can create general FGU accounts only in the new Loss Management application that uses overview
pages.
● You can use the old Loss Management application to edit losses for which there are general FGU accounts
provided there are no open activities for the losses.
Features
You can enter FGU accounts as:
● FGU Balance [page 662]

● FGU Movement [page 663]
12.1.1.2.5.1 FGU Balance
On the FGU Balance page, you can determine and change FGU balances.

The page consists of the following areas:
● Default Values
● Balance On <validity date/system status>
Default Settings
If there is no open activity, the system hides the Default Values area.
If there is an open activity, the system fills the following fields:
● FI Posting Date: system date

● Date of Receipt: the date on which the activity was entered; if you do not enter a date of receipt, the system
uses the system date.
● Account name: the name of the activity; if you do not enter a name in the activity, this field remains empty.
The system copies these entries to the FGU accounts that are created when a balance is changed.
You can change the default values using the Edit pushbutton under Default Values.
Balance On <Validity Date/System Status>
If there is an open activity, the system displays the balance on the validity date of the activity; if not, it displays
the balance on the system date.
The balance contains all the FGU accounts for the loss and cedent that have a validity date that is before or the
same as the validity date of the activity.
You can change the balance using the Edit pushbutton in this area. When you change the balance, the system
creates new FGU accounts or adds new postings to existing FGU accounts.
You can also add new rows for any missing combinations, for example for a combination of entry codes or
structural characteristics. You can do this using the New pushbutton or by entering rows in change mode.
You can use the Duplicate pushbutton to duplicate the rows in the balance overview.
You can delete balances only if these are new rows that you have not yet saved using the Save pushbutton in
the toolbar.
12.1.1.2.5.2 FGU Movement
This page provides an overview of the existing FGU accounts for the loss and cedent. You can create additional
FGU accounts and change or delete existing FGU accounts for an open activity.
You can use the Activity selection list to select the FGU accounts that you want to display:
● “Open”: you want to display the FGU accounts for the open activity
● “All”: you want to display all the FGU accounts for the loss and cedent

The standard system displays the accounts for the current open activity.
If there is no open activity, the standard system displays all the FGU accounts for the loss and cedent.
Creating FGU Movements
You can create FGU movements as follows:
1. On the FGU Movement main page, choose the New pushbutton.

2. A page appears that contains details of the FGU movement.
Default Settings
The system fills the following fields under Basic Data by default:
○ Validity Date: the valid-from date entered for information for the activity
○ FI Posting Date: current date
○ Account name: the name of the activity
○ Date of Receipt: date on which the activity was entered (if available) or the system date
○ Status: “Open”
3. Fill the required entry fields Original Currency and Business Type under Basic Data.
4. Choose the Save pushbutton to save the new account.
Alternatively, you can create an FGU account directly on the detailed page for the FGU movement by choosing
the New pushbutton or by entering additional rows in change mode.
You can use the Duplicate pushbutton to duplicate the rows. When you do this, the system does not copy any
postings.
On the detailed page for the FGU Movement main page, you can create, edit, duplicate, and delete postings for
an FGU account.
You can also enter, edit, and delete external references [page 723] and attachments and notes [page 659].
Editing FGU Movements
On the FGU Movement main page, you can use the Edit pushbutton to edit the header data of the FGU
accounts.
When you double-click the linked ID for an FGU account, the detailed page for this account appears.
Here you can edit the FGU account as follows:

For more information about navigating between pages and function control, see Control of Applications and
Pages [page 779] and Functions for Controlling Applications [page 780].

Reversing FGU Movements
On the FGU Movement main page, you can reverse the FGU accounts for an activity by selecting a closed
activity from the Activity selection list and choosing the Reverse pushbutton.
For more information, see Reversing Activities [page 661].
12.1.1.2.6 Coverages
Use
You can enter, change, and delete covering treaties and participations for a loss within a cedent. The treaty and
participation assignments apply across all activities.
Features
Creating Coverages
In the Loss Management application, you can create two types of coverage on the Coverages page by choosing
the New pushbutton under Coverages:
● Single risk coverage

● Treaty coverage
Default Settings
When you create a coverage the system fills the following fields by default:
● Rank: the system increases the coverage rank by one each time
● Reference Rank: 0: This field is not ready for input.
● Loss Area, Peril, and Main Currency: the system copies the data from the basic loss data
● Status and Reason for Change: the system copies the data from the cedent
● First Report Date and RI Assignment Date: the system copies the data from the basic loss data
● Account Transfer: the system sets this checkbox automatically
When you create, change, or delete a treaty coverage or single risk coverage, the system deletes the preview
data for the corresponding cedent automatically.
Creating Single Risk Coverages
The input help for the “Participation” field consists of two additional search helps:
● Original Policy
You can use this search help to find a participation ID only if the participations for a policy match the
structural characteristics of the loss.
● Participation
You can use this search help to find specific participations only if the participations match the structural
characteristics of the loss. Alternatively, you can search for the external reference for a participation.

The input help for the Loss Area, Peril, and Main Currency fields is only active after you have entered a
participation.
If you have added a valid participation, you can navigate to the participation by selecting the participation
name.
Creating Treaty Coverages
The input help for the “Treaty” field consists of two additional search helps:
● Covering Treaties
If you have created one or more FGU accounts, the system includes the structural characteristics of the
postings and lists only matching treaties in the search results.
● All Treaties
The system does not include the structural characteristics of the FGU account.
In both cases, the system includes the cedent currently being processed and the company code.
If you have not entered a treaty number, the input help for the Loss Area, Peril, and Main Currency fields is not
active.
If you have added a covering treaty, you can navigate to the treaty by selecting the treaty name.
Editing Coverages
You can edit coverages in the following ways:
● Using the Edit pushbutton in the toolbar

● Using the Edit pushbutton under Coverages
You can edit additional information about a coverage by choosing the Show/Hide Additional Fields pushbutton.
Deleting Coverages
You can remove coverages using the Delete pushbutton under Coverages.
You can delete coverages if you have deactivated the assignment check in Customizing in transaction SPRO
under FS-RI Reinsurance Basic System Default Values Edit Defaults for Accounting or the loss
expense for the coverage is zero.
If a coverage contains local LUDs, you cannot delete it.
12.1.1.2.7 Applicable LUDs
Use
On the Applicable LUDs page, the system displays the applicable LUDs for all coverages assigned to a loss and
cedent.
These are LUDs:
● That are currently valid for the loss according to their validity data
● From the underlying coverage
● That you have changed locally for the corresponding loss
Localize

If you have changed an LUD locally for the loss, the system sets the Alternative LUD checkbox and marks the
LUD in color on the main page.
Constraints
You can change LUDs only for the aggregation level Single Loss or Loss Object. You can change only LUDs from
a treaty coverage.
Prerequisites
To localize a loss object LUD, you have to enter an object that is assigned to the loss.
Activities
You can localize applicable LUDs in two different ways:
1. Select the required LUD row under Applicable LUDs.

○ Choose the Localize pushbutton.
○ A page appears that contains details of the applicable LUDs.
This contains the areas Details, Priority, and Liability. The last two areas are already activated for
localization and you can localize an LUD separately for each priority and liability or for both at the same
time; you can also return to the standard settings.
2. Navigate directly to the detailed page using a link from the Applicable LUDs main page. In this case, the
Priority and Liability areas are not automatically activated for localization.
Choose the Localize pushbutton in the corresponding area to localize an LUD.
Default Settings
If the underlying LUD contains values, the system fills the Alternative Indexation Method, Alternative
Reserve Limit, and Alternative Payment Limit fields by default.
○ Change these prefilled fields and choose Save to save the localization. The system sets the Alternative
LUD checkbox automatically.
○ If you want to localize only one LUD using alternative 1, choose the Standard pushbutton in each area
to reset the localization.
For more information about navigating between pages, see Control of Applications and Pages [page 779].
12.1.1.2.8 Preview
Use
If there is an open activity for the loss and cedent, you can view the results of the simulated loss account on the
Preview page.
You can enter postings manually, perform calculations, and finalize activities.

The preview is divided as follows:
● Preview of Cedent View [page 669]

● Preview of Details [page 670]
Features
If you navigate to the preview in edit mode, the system creates the preview automatically.
● FGU Calculation
If there are FGU accounts in the current open activity, the preview contains the results of the distribution of
the FGU accounts to the coverages.
If transfer postings to other losses are required for excess of loss data that applies to several losses (such
as annual aggregate limits (AAL) or event liabilities) due to the "FCFS" sequence of the loss account, you
can also view these in the preview.
● FGU Recalculation
If there are no FGU accounts in the current open activity, the system generates the preview by
redistributing all previous FGU accounts (FGU recalculation) and offsetting the existing loss figures.
 Note
It may be necessary to recalculate FGU accounts if the applicable LUDs for a loss have changed as the
result of new indexes.
It may also be necessary to recalculate these accounts if you reverse an activity that has already been
completed.
If there are coverages that contain excess of loss data that applies to several losses and there are other
losses with open activities for these coverages, the system returns messages to inform you that you may
have to generate the preview again for the other losses.
All the accounts that are created from automatic calculations are assigned the validity date of the activity.
This information is stored in the Start of Accounting Period and End of Accounting Period fields in the
account.
 Example
The system uses the accounting frequency entered in the reinsurance treaty to calculate which
accounting period (“Q1”) contains the validity date.
You cannot change these entries manually.
Finalize
You can use the Finalize pushbutton to close the editing of an activity.
When you finalize an activity, the system performs the following steps:
○ It transfers the accounts for single risk coverages to Basic System and releases these.
○ It releases the accounts for treaties.
○ If there are losses that are linked to the current loss through coverages because there is excess of loss
data that applies to several losses (such as annual aggregate limits (AAL) or event liabilities), the
preview data for these losses is invalid. You have to recalculate these losses.
○ The activity is given the status Completed.

Generating Previews
You can use the Generate Preview pushbutton to recalculate the preview.
It may be necessary to recalculate a preview if you have made changes outside the loss that are relevant for
calculation (for example, you have adjusted the surplus data in the treaty).
When you generate the preview, the system performs the following steps:
● It deletes the current preview data.

● It calculates FGU accounts (if there are FGU accounts in the open activity) or recalculates FGU accounts (if
there are no FGU accounts in the open activity).
12.1.1.2.8.1 Preview of Cedent View
This page consists of the following areas:
● Activity
● Cedent View
● Aggregate Utilization
Under Activity the system provides information about the relevant open activity.
Under Cedent View the system displays the simulated result of the current activity in summarized form.
The following functions are available in the toolbar under Cedent View:
● Account Level: You can use this selection list to display the aggregated preview either at section level or at
account level.
● Display Currency: You can use the input help for this field to select the currency in which you want to
display the amounts.
● Exchange Rate Type: You can use the input help for this field to select the required exchange rate type.
● Refresh Display: You can use this pushbutton to refresh the display after you have changed the display
currency.
The following functions are available in the toolbar for the page:
● Finalize: You can use this pushbutton to close the editing of an activity. For more information, see "Finalize"
under Preview [page 667].
● Generate Preview: You can use this pushbutton to generate the preview again. For more information, see
"Generating Previews" under Preview [page 667].
For more information about the structure of the user interface, see Structure of the User Interface [page 778].
If you enter a display currency with an exchange rate type, the system translates the amounts to be displayed
into the display currency using the exchange rates of the specified exchange rate type. The system translates
the amounts for reserve postings based on the most current exchange rate entered for the exchange rate type
and for payments on the translation date entered in the account.

12.1.1.2.8.2 Preview of Details
Use
On the Preview of Details main page you can display, change, and delete preview accounts.
Features
The system displays all the accounts for the current preview of the selected cedent.
The following functions are available in the toolbar for the page:
● Finalize: You can use this pushbutton to close the editing of an activity.
For more information, see Finalize [page 667].
● Generate Preview: You can use this pushbutton to generate the preview again. For more information, see
"Generating Previews" under Preview [page 667].
When you double-click the linked ID for a preview account, the detailed page for this account appears.
Here you can edit the preview account as follows:

For more information about navigating between pages and function control, see Control of Applications
and Pages [page 779] and Functions for Controlling Applications [page 780].
 Note
A preview account must contain at least one posting. Therefore, when you create a new account enter at
least one posting before you save the account.
If you want to delete all the postings for an account simply delete the entire account.
12.1.1.2.9 Evaluations
Use
On this page you can display the FGU trend for a loss and for a selected cedent in a graph.
The system displays the FGU reserve balance, the FGU payment balance, and the balance of the FGU incurred
losses at different dates and times over the course of the loss. The system also includes the FGU accounts from
activities that have already been completed and from the open activity.

Features
Under FGU Trend you can use the Personalize pushbutton on the right side of the toolbar to manage the layout
of the graph. For example, you can switch to 3D columns.
You can generate the graph in any currency.
Default Settings
● If you have entered a currency under Loss Basic Data , the system uses this currency as the display
currency for the graph.
● If you have not entered a currency in this basic data, the system uses the currency, and the exchange rate
type, that you have defined in Customizing for the loss company code. You can make this setting in
transaction SPRO under FS-RI Reinsurance Basic System Default Values Edit Defaults for
Accounting .
For more information, see the corresponding documentation in the system.
Activities
You generate an evaluation as follows:
● Enter an exchange rate type for translating amounts into the display currency. The system uses the most
current exchange rate to translate amounts, including payments.
● You can also restrict the period of the FGU trend in the Period From/To fields.
12.1.1.2.10 History Mode
Use
In the Loss Management application you can use the history mode to display an overview of all the historical
versions of a main page.
Features
You can switch to history mode on the following pages:
● Basic Data
● Objects
● Groupings
● Cedent
● Coverages
● Applicable LUDs

 Note
On the Applicable LUDs page the system displays only the historical dates and times for created or changed
local LUDs and not the historical time stamp of the underlying coverages and their LUDs.
Constraints
It is not possible to switch to history mode from the detailed page of the Applicable LUDs main page.
You cannot edit historical data. On the detailed page of the Applicable LUDs main page you can display only
historical statuses for the currently valid cedent. It is not possible to change the cedent automatically here.
Navigation
● You can use the History Mode pushbutton to switch in out out of history mode on those pages that support
the history mode function. If you make any changes on a page and do not save these before you switch the
mode, the system prompts you in a dialog box to reject these changes and continue or to cancel.
● You can use the History Overview pushbutton in history mode to switch to a different historical status.
● In the History Overview dialog box you can search for specific historical statuses.
● You can use the Historical Date/Time selection list to switch between different historical dates and times.
● You can use the Previous/Subsequent Historical Date/Time pushbuttons (arrow symbols) in the toolbar to
navigate to the previous or next historical date or time and compare these. Once you reach the oldest or
newest entry the pushbutton is no longer active.
● You can use the navigation tree to navigate in history mode between the main pages.
● When you navigate to another page in history mode, the system displays the historical status that is earlier
or the same as the time stamp of the current page. If there is no corresponding time stamp, the system
uses the oldest time stamp and displays the data for this historical status.
● If you want to navigate to a page in history mode that does not support this mode, the system displays a
corresponding error message and terminates the process.
● The system exits history mode when you choose the History Mode pushbutton again.
 Caution
Note that for coverages and applicable LUDs the system displays the historical statuses for specific
cedents. This means that for a specific time stamp the system displays the historical data for the currently
selected cedent.
If there is no historical data for a specific cedent for a time stamp in the coverages or LUDs, the system
finds the most recent cedent for this time stamp and displays the related data.
12.1.1.2.11 Loss Processing with Object Floorplan Instance

(OIF)
Use
The loss applications based on SAP NetWeaver Business Client (NWBC) support you in the management of
your losses and in the creation of accounts for these losses.

Unlike the classical SAP applications, the NWBC applications are more geared towards typical workflows. The
following applications are available:
● Loss Management [page 674]

● Loss Group Management [page 679]
● Close Loss [page 677]
● Loss Figures [page 677]
Prerequisites
For more information about working with losses, see Loss [page 611].
The following prerequisite also applies: You have defined the number range for internal number assignment for
the activity ID. You make this setting in Customizing for Basic System under Basic Settings Number Ranges
Activity .
Features
You can start the NWBC applications either in the NWBC environment or in a Web browser. However, if you are
using a Web browser there are some functional restrictions. It is not possible to navigate between transactions.
In the SAP environment, you call the NWBC applications in a Web browser using the FS-RI Web Dynpro
applications, which each start with WDY Application. You find these applications in the menu tree if you have
the corresponding role.
Field Help
You call the help for individual fields by selecting the field and choosing CTRL+F1.
Save
You can explicitly save data only at any certain points in the NWBC applications because the applications
automatically save data when the following actions are performed:
● Each time you confirm a change to a table

● Each time you switch to a different tab page
● Each time you switch to a different process step
Entering Additional Information
A side panel is provided in a number of areas to allow you to display additional information about the data being
edited.
You can show this information area by clicking the arrow on the right-hand side of the screen.
 Note
You cannot change the data displayed in a side panel.

The side panel can contain one or more information blocks, known as Collaborative Human Interface Parts
(CHIPs). The following CHIPs are delivered in the standard system:
● The “Overview of FGU” and “Treaty Figures” displays the current balance of the FGU accounts and the
treaty figures from activities that have already been finalized for the selected cedent. This CHIP is available
only in the area of loss management and only for cedent-dependent screens (from the activity onwards).
● The “Attachments” displays the information and files that were attached to the basic data for the loss,
activity, and FGU account. This CHIP is available in loss management, in the loss group, and in object
management.
 Note
The side panel exists only in NWBC. If you call the NWBC applications in a Web browser, the side panel is
not displayed.
12.1.1.2.11.1 Loss Management (OIF)
Use
You can use the Loss Management application in SAP NetWeaver Business Client (NWBC) to create, edit, or
display a loss in structured process steps. When you finalize the activity at the end of the process, the system
runs all the required accounting functions and posts the loss accounts in the connected current account
system.
Features
The following special functions are available in the Loss Management application:
● Loss Figures calls the loss figures [page 685] for the loss.
● History Mode allows you to display the status of data at any point in the past. This function is available only
on the “Loss”, “Cedent”, and “Coverage” tab pages, but not in create mode.
● Close Loss calls the application that is used to close a loss [page 649].
● Generate Preview and Finalize is displayed only on the Preview tab page.
Activities
Select and Create
When you call the application the Loss Management initial screen appears. This is where you can enter the
initial basic data for your loss.

You then have the following options:
● You can create a new loss by selecting Enter Loss Advice. You have to enter a cedent in order to do this.
● You can select a loss from the list of Losses Most Recently Processed and open this loss in change or
display mode.
● You can search for losses that match your specified data, select a loss from the search result, and open this
loss in change or display mode.
 Note
The system displays only losses for which you have at least display authorization.
Loss
This is where you enter general data about the loss, such as the loss date and the cause of loss. Depending on
your system settings, in addition to the selected fields you have to enter the persons who are responsible for
the loss and account.
You can assign a loss group and objects to the loss on the corresponding tab pages. You can create the objects
here or assign existing objects that have already been created in the corresponding FS-RI transactions.
Cedent
In this step, you enter the cedents that reported the loss to you or that sent you a loss advice. The cedent that
you entered when you created the loss is already entered. If more than one cedent is assigned to a loss, you can
switch between the cedents in the following steps to edit the relevant data.
Activity
In this step, you create the activity for the selected cedent. You can assign a target balance to the activity for
information purposes. The activity bundles all FGU accounts and any resulting derived accounts for the loss
cedent and therefore makes it easer to analyze the accounts.
If the first activity (and any subsequent activities) already have the status “Completed” or “Reversed” and you
want to enter other accounts, you have to create another activity. The corresponding tab page on this screen
provides an overview of any completed activities.
FGU Account
In this step, you enter from ground up (FGU) accounts for the loss with one or more postings.
The FGU accounts contain the gross amounts paid by the primary insurer. The system uses the FGU accounts
and the coverages assigned in the next step to calculate and generate the individual accounts with postings for
the current account system. It also generates accounts for the reinsurer shares. These are forwarded to the
current account when the activity is finalized.
If you enter additional FGU accounts after you have assigned treaties, you can if you want configure the system
to suggest only the structural characteristics of the assigned treaties in the input help (you do this in other
search helps). You can enter accounts as delta accounts or as balance accounts.
Unlike with previous accounts, you enter the difference in Delta Entry.
 Example
For example, the difference is EUR 50,000 if a loss that was first reported as EUR 100,000 is now being
reported as EUR 150,000. The system posts EUR 50,000 and notes the new balance of EUR 150,000.

You enter the new balance directly in Balance Entry.
 Example
The balance in the previous example is EUR 150,000. The system notes this balance and calculates and
posts the difference of EUR 50,000.
If you edit an account at a later date, you can then execute this account in delta or balance mode regardless
of which method you originally used to enter the account.
You can view the FGU accounts from finalized activities on the Finalized Activities tab page. You can call the
details for these accounts and their postings by selecting individual rows.
Coverage
This is where you assign the treaties that cover a loss (or parts thereof) to the respective loss. You must also
enter the sequence of this coverage for these treaties.
When you assign a treaty, the system offers you a preselection and, if requested, suggests in the input help only
those treaties whose periods, business partners, and structural characteristics correspond to those of the loss.
To configure this, select Covering Treaties as the Other Search Help in the dialog box for input help.
Preview
The preview shows the simulated result of the non-proportional calculation.
If you call the preview when you are in an open activity for which FGU accounts have been created, the
application reads the current loss balance and displays a current preview.
Update Preview
When you choose the Update Preview function, the application also checks whether changes have been made
to the treaty. If changes have been made, the system distinguishes between two cases:
● There is an open activity (and therefore also an FGU account). In this case, the application identifies the
new figures in the account and generates the current preview.
● There is no open activity and FGU account. In this case, before you can update the preview you have to
create an activity. When you choose the “Update Preview” function, a dialog box appears in which you
enter the posting-relevant data of the new FGU account. This new FGU account contains the necessary
adjustment postings.
Changes in the Preview
You can also change the results from the current activity directly in the preview. This type of change generates
adjustment postings. To do this, select a row and switch to the Adjustment tab page. Under Details you can find
information about these adjustment postings.
You can also enter additional postings.
When you are happy with the results of the preview choose Finalize.
Result
The Finalize function creates final accounts from the preview of the provisional accounts. It runs the necessary
functions and releases these accounts to the connected current account system. For more information, see
Release of an Account [page 634].
It also sets the status of the activity to “Completed”.

You can no longer change the activity. If you want to enter new accounts for the loss you have to create a new
activity.
12.1.1.2.11.2 Loss Figures (OIF)
Definition
Loss figures represent the cumulated amounts relevant to losses from a quantity of losses.
Use
You use loss figures for evaluations.
In the NWBC application Loss Figures, you can define the losses for which you want to generate figures based
on the available account, loss, and coverage information.
If you select Create Overview, the system displays the loss figures in a table.
12.1.1.2.11.3 Closing a Loss (OIF)
Use
You calculate a cedent's claim resulting from a specific loss, post this loss with the reserves, and then close the
loss.
You can call this function from the following locations:
● You can call this function directly and manually enter the loss for which you want to close a cedent's claim
or search for this loss.
● You call this function from the Loss Management application for the data that you are currently editing.
Prerequisites
In Customizing for FS-RI Reinsurance under Basic System Loss Program Control , you have used the
Clear Loss Reserves checkbox to indicate whether you want the system to clear reserves automatically.

Procedure
The function for closing a loss runs through the following process steps.
Enter Cedent
In step 1 you enter the cedent. The system displays only cedents that can still be closed.
Enter Periods
This is where you can enter period data for the FI posting date, accounting year, and accounting period. The
system uses this data to check the reserves balance and to transfer this balance, if necessary, to the
corresponding posting data.
Reserve Balance
The function displays the reserve balance.
Enter Additional Information
This is where you can enter additional information needed to close the loss. This includes information about
the activity, account, and loss status.
If there are no reserves to be cleared, you can enter information relating only to the loss status.
If there are reserves to be cleared and if the automatic clearing of reserves has been activated in Customizing,
you need to enter additional information about the activity and the resulting accounts.
Close Loss
After you have entered all the required data, select Close Loss.
Result
All the cedent's open claims for the loss have been posted and closed.
A confirmation screen appears containing the actions that have been performed and those that have not been
performed.
You can execute the following further actions from this screen:
● Close any other cedent claims for the loss

● Navigate to the loss
● Navigate to the loss overview
12.1.1.3 Cedent
Use
You can assign cedents to a loss from whom you have received messages about this loss.

Activities
Creating Cedents
In the Loss Management application that uses overview pages, you can create cedents as follows:
2. On the Cedent page, choose the New pushbutton.
3. Fill the required entry field Cedent ID.
Alternatively, you can use the input help and different search criteria to find cedents.
4. Choose the Save pushbutton to save the business partner entries.
Default Settings
If you have not set the Ced. Lock checkbox in Customizing for FS-RI Reinsurance under Basic System Loss
Edit Loss Statuses and the status in the basic loss data is not a copy status, the system copies the status
from the basic loss data to the cedent level.
Otherwise, the system sets an open status by default.
For more information about the status, see Managing Loss Statuses [page 686].
12.1.2 Loss Group Management
You use the Loss Group Management application to create, edit, and display loss groups. The system supports
you as follows:
● You can use classical loss group processing [page 679].

● You can use loss group processing [page 681].
Alternatively, you can edit loss groups using Loss Group Processing with Object Floorplan Instance (OIF) [page
684].
12.1.2.1 Classical Loss Group Processing
Use
Classical loss group processing is the same as processing a loss event.
Definition
A loss event is an event that results in multiple insurance-related single losses, such as the flooding of a region
or a large fire in an office building used by several parties.
Use
You can provide coverage for an event in a treaty. If a loss event occurs, the system uses the total amount of all
assigned single losses to determine the deductible and liability in the account.
Structure

Technically, a loss event is the same as a standard loss and can have a date, cause, and history. The difference
is that you can assign any number of single losses to a loss event.
The loss event is marked as such by the Loss Event checkbox in the loss header data.
Features
Automatic Generation of Loss Events Using a Background Job
SAP Reinsurance Management also provides a background job that recognizes loss events based on the
similarities between losses.
Creating a Loss Event
Just as with single losses, you can use the following transactions to create, edit, and display a loss event:
● /MSG/R_U1 (Create Loss)

● /MSG/R_U2 (Change Loss)
● /MSG/R_U3 (Display Loss)
The following steps describe how to create a loss event. You can then edit a created loss event.
1. Start transaction /MSG/R_U1 (Create Loss). The search screen appears.

The data that you enter here is used only for search purposes. It is not copied to the new loss event.
2. Choose the Create pushbutton.
3. Enter the required data and responsibilities, as well as any other information you want.
4. Set the Loss Event checkbox to indicate that the object being created is a loss event.
5. Choose Save to save the loss event. Since you have indicated that the loss is a loss event, the system now
displays an additional tab page entitled “Individual Loss Assignment”.
6. Switch to the Individual Loss Assignment tab page. This tab page contains two tables.
The assigned losses are listed on the left-hand side and the losses that match the event based on the
selection criteria entered on the same tab page above the two tables are listed on the right-hand side. The
system lists losses that have already been assigned to a different loss event in the matching losses for
information purposes.
This enables you to identify duplicate loss events.
It is not possible to assign a loss event more than once.
7. Check the selection criteria and confirm any changes by choosing the New Selection pushbutton.
8. To add matching losses to the event, select the losses and choose the Add pushbutton (arrow button)
between the tables.
9. To delete an assignment, select the loss in the assigned losses and choose the Remove pushbutton (arrow
button) between the tables.
10. To display the details for a loss listed in one of the tables, double-click the loss.
11. Set the required status for your loss event.
12. Choose Save.
Result
You have created a loss event.
Depending on the status, you can add additional single losses to this event later or use it to create an account.

12.1.2.2 Loss Group Processing
Use
Loss group processing is used to create, edit, and display loss groups and is based on a floorplan for overview
pages (OVP).
Prerequisites
For more information, see Loss [page 611].
Features
You access the OVP application in SAP NetWeaver Business Client (NWBC) under FS-RI 700_01 Loss
Processing Loss Loss Group Management .
The creation and editing of a loss group comprises the following steps and the process flow is described in the
following sections:
● Basic Data [page 681]

● Loss Assignments [page 682]
 Note
For more information about configuring SAP NWBC and the Web Dynpro applications, see Configuring Web
Dynpro Applications and SAP NetWeaver Business Client [page 781].
12.1.2.2.1 Basic Data
Procedure
You create a new loss group as follows:

1. On the search screen [page 778] in the Loss Group Management application choose the New pushbutton
under Results List.
2. The Basic Data page appears. You can enter information for the following areas:
○ Basic data
○ Duration

○ Classification
○ Amounts
○ Location
○ Responsibilities
○ External references
○ Attachments
○ Notes
Default Settings
When you create a loss group the system fills the following required entry fields by default:
○ Company Code: surrounding company code
○ Business Partner Role: You can configure the necessary roles and responsibilities in Customizing in
transaction SPRO under FS-RI Reinsurance Basic System Loss Edit Responsibilities for the
Loss .
○ Time Zone: surrounding time zone or system time zone
 Note
When you create a loss group the system copies the search criteria fields that you entered on the
search page. These can override the defaults settings for the company code and time zone.
3. Fill all the required entry fields.
You can also create, edit, or delete responsibilities [page 658], external references [page 658], and
attachments and notes [page 659].
4. Choose the Save pushbutton in the toolbar.
Results
You have created the loss group and you can edit this as follows:

12.1.2.2.2 Loss Assignments
On this page the system lists all the losses that are assigned to the loss group. Under Assigned Losses you can
use the Assign Loss pushbutton to assign losses to a loss group and the Remove Loss pushbutton or the
Remove action to delete assignments.
 Note
Note that if the loss group has a status with the category “Completed”, “Invalid”, or “Locked”, the Assign
Loss and Remove Loss pushbuttons are not active and you cannot assign or delete a loss.
For more information about the status, see Managing Loss Statuses [page 686].

Losses That Can Be Assigned
1. When you choose the Assign Loss pushbutton on the Loss Assignments page the Losses That Can Be
Assigned page appears.
2. This page comprises the Search Criteria and Losses That Can Be Assigned areas.
Search Criteria
The system copies the following search criteria from the basic data for the loss group and starts the
corresponding search:
○ Day of Loss
○ Day of Loss End
○ Area
○ Peril
○ Cause of Loss
○ Loss Category
○ Loss Consequence
○ Company code
You can deselect the Peril, Cause of Loss, Loss Category, and Loss Consequence fields as search criteria
manually or include them in a later search.
You can use the Find pushbutton to search again for losses that can be assigned. The system ignores
losses that have a status with the category “Completed” or “Invalid”.
You cannot deselect the Day of Loss, Day of Loss End, and Area fields.
If you have set the LossCoCd checkbox in Customizing in transaction SHI3 under FS-RI Reinsurance
Basic System Loss Program Control , the Company Code field cannot be deselected. In this case, the
system uses the company code from the basic data each time it searches for losses.
If you have set the Exact Assgmt checkbox in Customizing in transaction SHI3 under FS-RI Reinsurance
Basic System Loss Program Control , the system lists only those losses whose dates match this loss
group exactly.
Losses That Can Be Assigned
Here you can assign single losses to a loss group using the Assign pushbutton in the Actions column.
You can assign several losses to a loss group at the same time by selecting the losses from the Losses That
Can Be Assigned area and choosing the Assign Loss pushbutton.
Each time you assign a loss the system removes it from the list.
3. Choose the Completed pushbutton to return to the Assigned Losses page. The system does not save the
assignment.
4. Choose the Save pushbutton in the toolbar to save the loss assignments.
 Note
The system lists all the losses that are not yet assigned to the current loss group.
If you remove a loss that has already been saved and assigned to a loss group and do not save this action,
the deleted loss does not appear in the results list under Losses That Can Be Assigned.
Save the current status of the loss group after you have deleted the loss to ensure that this loss appears
again under Losses That Can Be Assigned.

Removing Loss Assignments
You can remove loss assignments in the following ways:
1. If you want to delete individual loss assignments, choose the Remove pushbutton in the Actions column
under Assigned Losses.
2. If you want to delete several loss assignments at the same time, select these losses under Assigned Losses
and choose the Remove Loss pushbutton.
In this case, you also have to confirm the deletion of the selected rows in a separate dialog box.
12.1.2.2.3 Loss Group Processing with Object Floorplan

Instance (OIF)
Use
You can use the Loss Group Management application with OIF to create, display, and change loss groups.
A loss group groups any losses.
You can use loss groups to define loss events or to group together losses for evaluation purposes (to use the
“Loss Figures” function of the NWBC applications, for example).
 Note
Single losses can be assigned to only one group. Loss groups cannot be assigned to higher-level loss
groups.
Integration
In SAP Reinsurance Management for SAP S/4HANA (FS-RI) a loss group is created as a loss, in which the “Loss
Group” checkbox is set. You can assign single losses to the loss that is selected as the loss group.
This means that you can save the same characteristics for a loss group as for a single loss.
Prerequisites
In Customizing for FS-RI Reinsurance under Basic System Loss Program Control , you have used the
Single Loss Assignment - Company Code checkbox to indicate whether the loss event and the assigned loss
have to be assigned to the same company code.

Activities
When you select a loss group from the search screen or when you create a loss group, the details of the loss
group appear.
On the Loss Group tab page you can enter information to describe the loss group.
On the Loss Assignment tab page you can use your own criteria to find the single losses that belong to the loss
group.
You can select the single losses in the search result to add them to the assigned losses.
You can also remove a loss that has already been assigned to the loss group in the same way.
On the Additional Information tab page you can attach any files to the loss group.
You can also navigate directly from the Loss Group Management application to the loss figures of the selected
loss group.
12.1.3 Loss Figures
Use
You can use loss figures to evaluate and display accounts with a loss reference for treaties or single risks.
Features
You access the loss figures in SAP NetWeaver Business Client (NWBC) as follows:
1. You can open the loss figures under FS-RI 700_01 Loss Processing Evaluations Loss Figures .
2. You can open the loss figures in the Loss Management, Loss Group Management, or Object Management
application using the You can also pushbutton.
3. You can open the loss figures in the Loss Management or Loss Group Management application using the
integrated Loss Figures pushbutton.
The structure of the loss figures is the same as that of the search screen and consists of four areas for entering
search criteria.
Search Criteria
The search criteria is divided into the following areas:
● Control Criteria: Here you can enter basic settings for the search and evaluation.
● Loss Criteria: Here you can restrict the search to specific losses, loss groups, or activities.
● Account Criteria: Here you can restrict the search to specific accounts, cedents, or structural
characteristics.
● Coverage Criteria: Here you can restrict the search to specific treaties, participations, or policies.

 Note
Avoid entering unspecific search criteria and search operators because this can result in a very large
selection of data and very long response times.
Default Settings
When you search for loss figures the system fills the following required entry fields under Control Criteria:
● Evaluation Level: “ALL”

● Account Level: “INVOLVEMENT”
● Accounting Principle: “CEDENT VIEW”
● Key Date: current date
When you start the Loss Figures application, the system displays and expands the Control Criteria area so that
you can see all the filled required entry fields. All the other areas are collapsed and theirs fields are not visible.
Results List
The fields displayed under Results List are included when the system evaluates the aggregation-relevant
criteria (with the exception of text fields, currency fields, and amount fields). This enables you to group your
evaluation by specific fields.
For more information about the layout options for the results list, see Functions for Managing Tables [page
781].
12.1.4 Managing Loss Statuses
Use
The effects of the loss status in the Loss Management and Loss Group Management applications are described
here.
You can enter a status in a loss on the following pages:
● Basic Data
● Cedent
● Coverage
Prerequisites
You can enter a status in a loss group at basic data level only.
You can set a status with the category “Locked” at a higher level only if all the corresponding lower levels in the
Loss Management application have a status with the category “Locked” or “Completed” or if the status is
propagated.
If you have set a status with the category “Open” at a higher level (not “Invalid”, “Locked”, or “Completed”),
you can also set this status at a lower level.

Features
You can configure the corresponding loss category in Customizing for FS-RI Reinsurance under Basic System
Loss Edit Loss Statuses .
If a status is locked for a specific loss level in Customizing, you cannot set this status for the corresponding
level using the input help or manually.
The reason for a change is propagated according to the status.
If you change the reason for a change without changing the status, this is not propagated.
If you want to propagate different statuses from several cedents or coverages at higher levels, the system uses
any status from one of the lower levels for the higher level.
It is not possible to propagate statuses between loss groups and losses.
The status does not affect notes and attachments.
The system propagates the statuses in the APIs according to the Customizing settings.
 Note
For more information about propagating statuses, see the corresponding system documentation in
transaction SPRO under FS-RI Reinsurance Basic System Loss Edit Loss Statuses .
12.1.4.1 Setting and Propagating Statuses
You can manage the status in the Loss Management application that uses overview pages in transaction SPRO
under FS-RI Reinsurance Basic System Loss Edit Loss Statuses .
Status in Basic Data for Loss
Status with the category“Locked”
You can set the status of the loss using the input help or manually in the Status field.
You can set this status only if an assigned loss group does not have a status with the category “Completed”.
Status with the category“Open”
You can set this status only if an assigned loss group does not have a status with the category “Completed” or
“Locked”.
Status at Cedent Level

Status with the category“Open”: There are no effects.
Status at Coverage Level
Status in Basic Data for Loss Groups
You cannot set the status using the input help or manually in the Status field.
 Note
You cannot set the following status categories if you are processing losses using overview pages:
● “Invalid”
● “Completed”
● “Copy”
12.1.4.2 Dialog Control If Status Already Set
The effects of an existing set status in the Loss Management and Loss Group Management applications are
described here.
Status in Basic Data for Loss
Status with the category“Completed”
None of the fields can be edited and you cannot run any actions at loss level.
You can edit only the Status and Reason for Change fields in the basic data and at cedent and coverage level.

● You cannot create, change, delete, reverse, or finalize activities.
● You cannot create, change, or delete FGU accounts.
● You cannot create or change a preview.
● You cannot edit the cedent assignment and the corresponding coverage assignments and applicable LUDs.
● You cannot delete cedent assignments.
Status with the category“Invalid”
None of the fields can be edited and you cannot run any actions at loss level.
Status at Cedent Level
None of the fields can be edited and you cannot run any actions from cedent level. You cannot delete the
cedent assignment. You can edit only the Status and Reason for Change fields at cedent and coverage level.
● You cannot create, change, delete, reverse, or finalize activities.

● You cannot create, change, or delete FGU accounts.
● You cannot edit the cedent assignment and the corresponding coverage assignments, including applicable
LUDs.
● You cannot delete the cedent assignment.
None of the fields can be edited and you cannot run any actions at cedent level. You cannot delete the cedent
assignment.
Status at Coverage Level
None of the fields can be edited and you cannot run any actions at coverage level and for the applicable LUDs.
You can edit only the Status and Reason for Change fields. You cannot delete the coverage.

● You cannot finalize or reverse activities.
● You cannot edit the coverage assignment.

● You cannot delete the coverage.
None of the fields can be edited and you cannot run any actions at coverage level. You cannot delete the
coverage.
Status in Basic Data for Loss Groups
None of the fields can be edited and you cannot run any actions. You can edit only the Status and Reason for
Change fields in the basic data for the loss group.
There are no effects at loss group level. For information about the effects in the assigned losses, see the status
in the basic data for the loss. You cannot edit single loss assignments.
None of the fields can be edited and you cannot run any actions at loss group level. You cannot edit single loss
assignments. If you set this status, the system deletes these automatically.
Status with the category“Open”
There are no effects. Even if a loss group has a status with the category “Open”, you cannot assign losses with a
status with the category “Completed” or “Invalid”. You can assign losses with a status with the category
“Locked”.
12.2 Reinsurance Program
Definition
The reinsurance program (also RI program) maps a hierarchical sequence of ceded reinsurance treaties or
retrocessions. This enables you to determine the order in which the treaties are applied to cover a risk.
The reinsurance program has two formats but when you create new reinsurance program periods, the system
supports only the newer, more flexible format. In contrast to the current format, the more flexible format
provides the user with more options to specifically reference a liability extract. It also allows the user to merge
proportional and non-proportional treaties in a reinsurance program period and arrange these in a hierarchy.
Use
You use reinsurance programs to distribute individual risks to matching reinsurance treaties.

● In Risk Manager Non-Life, reinsurance programs form the basis for calculating cessions [page 95] for a
cession group [page 125].
● In Basic System, the reinsurance program helps to distribute losses to the respective ceded treaties.
Structure
For each reinsurance program, you define certain parameters that apply across the entire program, such as
Partner, Period, and Class Model.
In Risk Manager reinsurance programs, you also enter data relating to cession calculation, such as the
Standard Cession Calculation checkbox. You enter the data for the individual coverage layers in the table as
follows.
Header Data
You use ranks to define the hierarchy of the treaties (or retentions/unplaced risks). Depending on the rank
category, each rank is assigned to a ceded obligatory treaty, a retention, an unplaced risk, or a threshold value
that controls the amount of the additional retention.
For more information about assigning treaties, see Assigning Treaties to a Reinsurance Program [page 694].
You use the reference rank to control the liability amount, which represents the calculation base of the rank. In
reinsurance programs with a flexible format, you can use the reference rank for all rank categories in both
proportional and non-proportional treaties. In the current format, however, the reference rank is available for all
rank categories but cannot be used for non-proportional treaties.
In order to specify the relevant liability extract of a rank, you must enter a coverage reference for the reference
rank in reinsurance programs with a flexible format.
The following coverage references are available:
● TOTLB – total liability of reference rank

● RETEN – retention of reference rank
● XSAMT – excess amount of reference rank
● UNCSR – uncovered share of reference rank (total of RETEN + XSAMT)
● UPRSK – remaining unplaced risk that exists based on the reference rank
Reinsurance programs in the current format always work with the unplaced risk of the reference rank.
You can also structure the retention in a more flexible format. You must make this setting in the rank categories
“Treaty” and “Retention/Additional Retention”.
To handle the retention using the cession calculation function, you can select the following options:
● RIPRA – transfer the retention to the applied retention

● IGNOR – retention is not included
● PREV – retention is already covered by previous ranks
● SUBSQ – retention is covered by subsequent ranks
The handling of the retention in reinsurance programs in the current format is controlled by the maximum
liability checkbox at RI program cession level.
Constraints

● The coverage reference TOTLB can be entered only if the reference rank is 0.
● The coverage references RETEN, XSAMT, and UNCSR can be entered only if the reference rank is not 0.
● The retention control IGNOR is not permitted if the rank category is “Treaty” and “With Non-Proportional
(NP) Treaty”.
● The retention control RIPRA is only permitted if the rank category is “Retention/Additional Retention”.
● If the reference rank does not equal 0, the values that can be entered for the coverage reference depend on
the settings made to control retention in the reference rank. For example, the coverage reference cannot be
used to refer to the retention in a reference rank if this coverage reference transfers the retention to the
applied retention. The use of the reference rank 0 implies that the coverage reference TOTLB has been
entered.
Reinsurance program ranks with the rank category “Treaty” and “With Non-Proportional (NP) Treaty” display
the deductible, liability, and protected share from the treaty definition. The protected share is applied based on
the LUD data. Depending on the arrangement of the treaty, it is also applied to the calculation base and the
FGU amount. The Ignore Protected Share for Coverage Reference checkbox provides information about this and
overrides the amount reference in the treaty data.
Details of RI Program Cession
For retentions and proportional treaties, you double click the table row to go to the detail screen for the
corresponding rank. On the detail screen you can then enter class-specific values for the rank in question.
For more information, see Reinsurance Program Cession [page 692].
Example
For an example of the process, see Example: Creating Reinsurance Programs [page 695].
 Note
You can transfer a reinsurance program to the new flexible format manually by adding the entries for the
coverage reference and retention control to the rank definitions. However, you cannot return a reinsurance
program to its previous format.
12.2.1 Reinsurance Program Cession
Definition
If the ranks in the reinsurance program [page 690] have the category “RIP Retention”, “Treaty” (proportional
only), and “Additional Retention”, you can add further details in the reinsurance program cession.

Structure
If you double click a row for a cession in the reinsurance program header data, the detail screen for the
reinsurance program cession appears.
On the detail screen you can define the share assigned to the treaty individually for each class.
The treaty type determines which fields are available for restricting the cession to the treaty, such as Retention,
Maximum Liability, or No. of Lines. You can restrict the cession to the treaty by defining a lower liability than the
limits defined in the treaty itself. However, you cannot a liability that exceeds that of the treaty.
In the case of surplus treaties, you can also restrict the cession by defining a quota share percentage and the
maximum liability.
You can use the maximum liability indicator to control how the retention in reinsurance program cessions with
the previous format is handled. This retention is either assigned as applied retention (RET) or forwarded to the
next rank via the unplaced risk.
For more information, see Assigning Treaties to a Reinsurance Program [page 694].
Constraints
● Surplus treaty and retention: You are not allowed to enter the combinations Quota Share/Maximum
Liability and Retained Line/No. of Lines together. The system accepts only the combination Quota Share/
Maximum Liability or Retained Line/No. of Lines.
● Surplus treaty: You are not allowed to combine the fields “Quota Share/Maximum Liability” and “Utilization
%”.
Integration
You create the default class model in Customizing for Basic System under Interfaces RM Connection RIP
Settings Define RIP Class Model .
12.2.2 Functions for Editing Reinsurance Programs
You can use the following functions to edit reinsurance programs (RI programs).
Create/edit reinsurance program In the FS-RI role menu, choose Basic
System RI Programs Reinsurance
Program .

Create new reinsurance program pe In the header data for the reinsurance When you create a new period, the sys
riod program, you can use the Create New tem sets the end date of the preceding
Period pushbutton to create a new rein period to the day before the new period
surance program period for the se starts.
lected reinsurance program.
12.2.3 Assigning Treaties to a Reinsurance Program
Prerequisites
General
The treaty you assign to a reinsurance program must fulfill the following prerequisites:
● The status of the treaty allows posting and is not a reversal status.
● The treaty has the same cedent as the reinsurance program.
● The treaty has the same term as the reinsurance program.
 Note
By default, every reinsurance program you create is valid until December 31, 9999. To restrict the validity
period for a reinsurance program, you create a new reinsurance program period. The original period then
ends on the day before the new period begins.
Risk Manager
If you want to use a treaty in a Risk Manager reinsurance program, it must also meet the following
requirements:
The Use in Risk Manager checkbox must be set at treaty header level.
In the case of a non-proportional treaty, the Cession Calculation checkbox must be set for the LUD.
The protected share of an NP treaty is applied to the LUD data. Depending on the arrangement of the treaty,
this is also applied to the calculation base and the FGU amount. The Ignore Protected Share for Coverage
Reference checkbox provides information about this and overrides the amount reference in the treaty data.
If you want to map intra-company retrocession using the reinsurance program, the Create Assumed Business
Side in Risk Manager checkbox must be set in the treaty. For more information, see Obligatory Connecting
Treaties in the Reinsurance Program [page 104].
Procedure
1. In the Header Data table in the reinsurance program, choose rank category “1” (treaty).
2. Enter the Treaty Number in the corresponding column.

 Note
If you are building a reinsurance program based on hierarchically arranged treaties, you must make sure to
describe the arrangement in relation to the sequence from the outside to the inside. This means that the
treaty that covers the retention of a different treaty must be arranged as follows.
 Example
Example: Protection of the NP Deductible by a Quota Share
Reinsurance program 1 – correct definition: the quota share is only covered within the NP deductible in the
account
Rank Reference Rank Coverage Reference Treaty Control Retention
1 0 TOTLB (total liability) NP SUBSQ (subsequent

ranks)
2 1 RET (retention) Quota RIPRA (transfer to re

tention in RI program)
Reinsurance program 2 – incorrect definition: the quota share is not covered by the NP deductible in the
account
Rank Reference Rank Coverage Reference Treaty Control Retention
1 0 TOTLB (total liability) Quota, maximum lia RIPRA (transfer to re

bility = NP deductible tention in RI program)
2 1 XSAMT (excess NP PREV (previous

amount) ranks)
12.2.4 Creating Reinsurance Programs
Use
Create a reinsurance program using the following data. For more information, see the documentation for
reinsurance programs.
Procedure

1. Enter the individual values:
Name of Reinsurance Program: PROG1
Partner: your owner company
Module: Risk Manager
Class Model: If you have defined the optional class model in these examples (FIRE), enter this class model
here. If you have not defined this class model, create the reinsurance program without a class model.
Ranks: For ranks 1 and 2 of the reinsurance program, enter the master treaties AUSG_VTGQU and
AUSG_VTGSU that you created previously. Rank 2 covers the part of the risk that exceeds the quota share
liability. The quota share retention and retained line of the surplus treaty are copied to the unplaced risk of
the next rank via retention control.
For rank 3, enter facultative cover. This is just a placeholder and controls whether proportional facultative
participations can be added to a cession group that references the corresponding reinsurance program.
Do not define any retention control for facultative placeholders.
Rank Reference Coverage Ref Rank Category Name Treaty Control Reten
Rank erence tion
1 0 Total liability 1 Treaty ausg_vtgqu Retention is

not included
2 1 Unplaced risk 1 Treaty ausg_vtgsu Retention is

not included
3 2 Unplaced risk 3 Proportional

facultative re
quirement
Status: INPRO
Currency and Exchange Rate Type: EUR and M
2. Confirm your entries for the ranks.

Defining the Cessions
1. You can now enter the cessions for the first two ranks. If you have defined the class model, you can enter
cessions for each class in the class model. If not, the cessions can be entered independently of class. In
either case, the total cessions must not exceed the maximum capacity of the master treaty.
2. To enter the details, double click the rank. The RIP PROG1 Change: RIP Cession screen appears. Enter the
quota share percentage.
4. If you have not created a class model, enter the data specified below for class A.
Cession for Quota Share Treaty
A Class A 100 10,000,000

B Class B 20 10,000,000
Cession for Surplus Treaty
Class Name Retained Line Number
A Class A 1,000,000 7
B Class B 500,000 8
5. Set the status to “Processing Completed”.

12.3 Bordereau Manager (Basic System and Risk Manager)
A bordereau is a structured set of postings in a compact format. Unlike the accounts in the FS-RI system, each
line item in a bordereau contains all the relevant information. This enables you to enter or change data that
belongs to different accounts at the same time.
In addition to absolute difference postings, you can also enter balance postings in the bordereau to define the
status of specific posting criteria without knowing their previous history. It makes sense to do this for reserves,
for example.
The line items entered with Bordereau Manager are initially saved in this format. This provisional data can be
changed or deleted at any time. Once you have entered all the data, you can generate accounts from the
bordereau data. After you have generated the accounts, you can still change the bordereau postings (with the
exception of balance postings), provided the generated accounts have not yet been released. You must
generate an account again after you have changed a bordereau posting.
Bordereau accounts are commonly used for single risks. The sender (often the cedent) supplies the
bordereaux that are to be mapped 1:1 in Risk Manager. Nevertheless, a similar transaction is provided in Basic
System. Bordereau Manager can also be used for collective data entry. In this case, you use a user ID instead of
a specific bordereau number to enter the data.
You can use the accounting function to continue processing generated accounts from the bordereau. To do so,
select the bordereau line item that references the account and choose the relevant function.
12.3.1 Generation of User-Specific Bordereaux
At present, there is no preconfigured function for generating bordereaux for a specific accounting dataset.
However, you can implement customer-specific solutions using standard SAP tools. This is relatively easy since
all the relevant information has been stored in two or three transparent tables in the /msg/ namespace. In
contrast to Basic System, no other SAP system components are involved. For example, you do not need to
extract data from the system for accounts payable/receivable.

12.3.1.1 Data Model for Accounting
The account data is stored in two tables:
● Account table /msg/RABR with the primary key ABRNR (account number): each row of this table contains
the header data of an account, which applies to all the postings contained therein.
● Posting table /msg/RBU with the primary key ABRNR (account number) and BUNR (posting number): this
table contains all the posting line items. At the same time, the field ABRNR is the foreign key for the account
table, and uniquely identifies the correct account for each posting.
If you use the bordereau function to enter account data (and specify a bordereau number), the system also fills
the following assignment table:
Table /msg/RBORD_ZUO, with the keys fields BORDERO_NR (bordereau number), ZEDENT (cedent) and LFD_NR
(sequence number of the line item as entered in the screen). This table assigns an existing account and posting
to each line item in the bordereau using the fields ABRNR and BUNR. The assigned account may have been
processed further since creation. Therefore, if the bordereau number and cedent are known, you can read all
the relevant postings and corresponding account data (which may involve several accounts), and process the
data further.
[[Figure]]
12.3.1.2 Display of Existing Bordereaux
If bordereaux have already been entered in the system using Bordereau Manager, and a bordereau number has
been entered, you can reconstruct these bordereaux.
Based on the assignment table, the system reads the relevant postings and accounts from the database and
displays them line by line according to the sequential number of the line item. Since a bordereau can generate
more than one account, the account data is included in each posting item (also see the entry screen).
If you do not want the postings to be displayed in the same way as on the entry screen, you can group them by
account (group level). In this case, the assignment table is only needed to determine all the accounts that
originate from the bordereau. These accounts may also contain additional postings that have been generated
automatically, such as subpostings, or postings created by the Calculate function. These postings are not
included in the assignment table, and may be filtered out.
Note: Bordereau Manager also uses two other tables for the bordereau headers and bordereau line items
respectively. However, these tables are not necessarily required to display the posting data. Once a bordereau
has been processed, it should have the status Generated. In this status, the bordereau no longer has explicit
line items, and the bordereau header is redundant. All the relevant information is stored in the accounts and
postings.
12.3.1.3 Display of Generated Accounts
You can also display a generated account (such as a retrocession account) as a bordereau. In this case,
however, there are no entries in the assignment table. On the basis of the account number, the system has to
read all the corresponding postings and display them line by line. You can opt whether to display the common

account data as a header or in each posting item. In the case of outgoing bordereaux generated by the owner
company code, it makes sense to generate a bordereau number. If each account corresponds exactly to a
bordereau, you can use the account number as the bordereau number. This saves you from having to make
additional technical settings (number ranges, persistent storage of the number and assignment).
12.3.2 Creating Bordereaux
When you create a bordereau, you must enter the sender (a company often the cedent or broker) and a
bordereau number. The combination of these two entries must be unique, and cannot be changed later. The
bordereau number is not assigned automatically, since it is used primarily as an external reference. If you want
to use the bordereau function for collective data entry, you can choose any bordereau number.
A bordereau is created in the logon company code, and can only be used to create postings for participations
(Risk Manager) or treaties and sections (Basic System) that are in the same company code. The financial
accounting framework (financial accounting date, financial year, accounting period) is also defined globally for
all entries.
You enter the account and posting data line by line. For each line item, you enter the entry code and the amount
in the original currency. You can also enter values for some of the required fields in the first line item, which can
then be copied to the rows below. In Risk Manager, the system enters structural data automatically when you
enter the key data for the relevant participation (if you have not already entered the structural data manually).
The fields for the account number, posting number, and reversal indicator are not relevant when you create a
bordereau. New bordereaux always have the status Temporary.
When you save your data, the system switches to change mode.
12.3.3 Changing Bordereaux
You can change or delete temporary bordereau line items at any time. Temporary line items are those that have
not been used to generate accounts. You can also create new line items.
You can also change bordereau line items for which accounts have already been generated, provided these are
not balance postings and the accounts have not yet been released.
The bordereau does not display subpostings that are created automatically in Risk Manager from existing
original postings on the basis of specified time frames. The result is a compact view of the current bordereau
entries.
If accounts are processed further, the system also displays some of the resulting generated accounts and
postings in the bordereau. For example, you can use the bordereau to check the results of calculated
conditions.
12.3.4 Deleting Bordereaux
You cannot delete a bordereau with the status Generated or Extended, since this means accounts have already
been created on the basis of the bordereau, or provisional entries still exist. You can only delete bordereaux

with the status Temporary that do not have any entries. If a bordereau no longer has any provisional entries and
all the accounts relating to this bordereau have been deleted on the accounting side, you can opt to delete the
bordereau immediately on the accounting side. If you decide not to delete it straight away, the system sets the
status of the bordereau to Temporary, which enables you delete it manually. If you delete the postings from the
last account linked to a bordereau, and the bordereau no longer contains provisional entries, you have the
same options as for deleted accounts. Once you have chosen whether the bordereau should be deleted
immediately, or whether only the status should be changed, the system also deletes this last account.
12.3.5 Copying Bordereaux
This function is currently only available in Basic System.
It enables you to use an existing bordereau as a template for creating a new bordereau. The header data is
copied from the template and cannot be changed in the new bordereau. The target balance is not copied. The
system also copies the line items from the template, regardless of whether they are provisional or generated. In
the new bordereau, all the entries are provisional and can be changed or deleted.
12.3.6 Generate
Use
You trigger the “Generate” function when you have finished entering data for the bordereau. The function uses
this data to generate accounts that can be processed further in the system. You should execute the “Generate”
function only when you have completed all the bordereau entries. As long as accounts and postings have not
been generated for the bordereau, the line items that can be changed are stored separately from normal
posting data.
Activities
When you execute the “Generate” function, the system:
● Generates postings and accounts from the temporary bordereau line items
● Eliminates all redundant information
● Sets the bordereau status to “Generated”
Generated Accounts
If the system find bordereau postings that have a sufficiently similar structure to be included in an account, it
compiles these in an account.
The accounts created during generation have the following statuses:
● Basic System
Accounts created in a Basic System bordereau are assigned the status Pending.

● Risk Manager
Accounts generated from a Risk Manager bordereau are assigned the status that was configured for this
purpose in Customizing. You make this setting in external Customizing for Risk Manager under Default
Values Edit Defaults for Accounting . The following settings are available:
○ Pending
○ To be Split or To Transfer to Basic System by Batch (the system chooses the latter status if accounts do
not need to be split)
12.3.7 Reversal of Bordereau Entries
You can use the Reverse function to create offsetting postings automatically for bordereau entries that have
already been generated. This is only possible if the corresponding accounts have been released. You must first
select the generated bordereau entries you want to reverse. If you execute the Reverse function without
selecting any entries, the system attempts to reverse all the bordereau entries. Any errors that occur during
the reversal are listed in an error log after processing.
 Caution
We recommend using the Simulate Reversal function before the Reverse function.
12.3.8 Simulation of a Reversal from a Bordereau
When you generate postings and accounts for a bordereau, you can group several bordereau entries in an
account, which then contains various postings. This means that several line items in the bordereau can have
the same account number, but different posting numbers. If you reverse a generated bordereau entry that
shares the same account with other bordereau entries, the system also reverses the related bordereau entries
(the reversal is performed for the entire account). To ensure that this does not happen by accident, you should
simulate the reversal first. The Simulate Reversal function checks whether the selected entry is linked to other
entries in the bordereau and highlights the line items affected. This gives you an overview of bordereau line
items affected by the reversal.
 Note
If you want to reverse individual postings only, create the corresponding offsetting entries manually.
12.3.9 Segmentation of Bordereau Entries
You can use this function to group generated or non-generated bordereau line items into segments and
evaluate the calculation base totals (such as the technical result, losses incurred, gross premium, cash
balance).
The system totals these calculation base totals for the selected segment. A new Segment field has been added
to the table control. In the standard Bordereau Manager settings, this is the first field.

Segment (field in the table control):
This field indicates the number of the respective segment. Until a line item is assigned, the default entry is 0.
The numbers of entries belonging to a segment start with 1 and continue sequentially. If you delete a segment
entry, the value in the Segment field is reset to 0.
When you make changes (delete segment, define segment) the system reassigns the segment numbers to
keep them in sequence. It then sorts the bordereau line items in ascending order on the basis of the segment
number.
The following segmentation buttons have been added to the toolbar:
● Start of Segment
● End of Segment
● Segment(s) -> Segment
● Line Item(s) -> Segment
● Delete Segment
Start of Segment
When you select a line item in the table control and choose Start of Segment, the system enters the next
segment number in the Segment field for this row, starting with 1 and ending with 9999. You should make sure
that the selected line item is not already assigned to a different segment.
End of Segment
You use this function to define the end of a segment. This is only possible if a line item has already been defined
as the start of the segment. All the entries from the start of the segment to the end of the segment are then
grouped into one segment, as long as they do not already belong to another segment. If you assign the end of a
segment to a line item that already belongs to a different segment, the system only adds the line items that
have not yet been assigned to a segment to the new segment. The existing segments remain unchanged. The
segments are then sorted in ascending order.
Segment(s) -> Segment
You use this function to add existing segments to other segments. To do this, you first select one line item from
each of the segments you want to add to the target segment and choose Segment(s) -> Segment. In the dialog
box that appears, you then enter the segment number of the target segment. The system merges the
segments and reassigns the segment numbers. You can also add an existing segment to segment 0 to initialize
or delete it.

Line Item(s) -> Segment
You can also add individual line items to an existing segment. You do this by selecting the relevant line items
and assigning them to a target segment in the same way as the function Segment(s) -> Segment.
Delete Segment
This function enables you to delete segments more easily. You simply select one line item in the segment, and
the system deletes all the assignments to this segment.
Evaluating the Calculation Base Totals for the Segments
If you have created several segments for a bordereau, and double-click a segment, the system evaluates the
calculation base totals for this segment. You need to double-click the Segment field in the table control.
Double-clicking the other fields either has no effect, or calls up a different function. To return to the total values
for the bordereau, you have to double-click an empty row in the table control, or an entry in segment 0.
You can also display the calculation base totals for the entire bordereau or for a certain segment in a specific
currency.
To do this, first choose the currency in the Display Currency field, and then set CrcyTrans. (currency translation)
or Cur.Filter (currency filter) checkboxes.
Currency Translation
If you select this option, all the entries for the bordereau or segment are included in the calculation base totals.
If different original currencies were used, these are simply translated into the selected currency.
Currency Filter
If you select this option, the system only includes the bordereau or segment entries in the calculation base
totals if the original currency matches the currency entered in the Display Currency field.
12.3.10 Balance Postings in Basic System Bordereau
Use
You can create a posting in the bordereau where the amount entered is not the amount to be posted but is the
target amount for the total of all postings for the specified criteria. When you choose Generate [page 700], the
system calculates the incremental amount that is required to calculate this total target amount and it creates a
corresponding incremental posting.

Features
Activating the Balance Posting Function
To ensure that the system enters balances instead of independent posting amounts when you create the
bordereau, you have to set the “Liquid Items as Balance” or “Non-Liquid Items as Balance” checkboxes.
Calculating the Relevant Balance
The system calculates the balance from the total amounts of all postings that have the same characteristics as
the balance posting. It then compares the balance with this balance posting to calculate the increment to be
posted. This includes the following characteristics:
● Accounting unit
● Occurrence date
● Occurrence year
● Share number
● Section number
● Entry code
● Extended posting
● Area
● Business type
● Object number
● Loss number
● Treaty number
● Cedent
The system includes only those postings that meet the following prerequisites:
● The posting comes from Basic System

● The account for the posting has the status “Released” or “Distributed”
● The end date of the accounting period for the account containing the posting is not after the end date of
the accounting period for the balance posting
Example
1. A reserves entry code exists with a specific combination of the aforementioned criteria. The following
postings are made for this entry code:
○ Posting A: USD 500
○ Posting B: USD 800
○ Posting C: USD 900
2. You want to enter a new reserves balance of USD 2000 and create the corresponding balance posting.

3. You generate the account for this balance posting.
4. When it generates the account, the system calculates the total amounts from posting A, posting B, and
posting C (= USD 2300), compares this total with the amount entered for the balance posting (= USD
2000) and posts the difference in the generated account (= - USD 300). If you do not set the Post
Differences checkbox in Customizing for Basic System under Default ValuesEdit Defaults for Accounting
(Calculation Fields) , the system does not post the difference but creates an offsetting entry for the old
balance and a complete posting for the new balance.
12.3.11 Balance Postings in Risk Manager Bordereau
Use
You can create a posting in the bordereau where the amount entered is not the amount to be posted but is the
target amount for the total of all postings for the specified criteria. When you choose Generate [page 700], the
system calculates the incremental amount that is required to calculate this total target amount and it creates a
corresponding incremental posting.
Features
Activating the Balance Posting Function
To ensure that the system enters balances instead of independent posting amounts when you create the
bordereau, you have to set the “Liquid Items as Balance” or “Non-Liquid Items as Balance” checkboxes.
Calculating the Relevant Balance
The system calculates the balance from the total amounts of all postings that have the same characteristics as
the balance posting. It then compares the balance with this balance posting to calculate the increment to be
posted. This includes the following characteristics:
● Occurrence date
● Occurrence year
● Share number
● Entry code
● Extended posting
● Area
● Business type
● Object number
● Loss number
● Treaty number
● Cedent

● Accounting year
The system includes only those postings that meet the following prerequisites:
● The posting comes from Risk Manager

● The account for the posting has already been transferred to Basic System
● The end date of the accounting period for the account containing the posting is not after the end date of
the accounting period for the balance posting
Example
1. A reserves entry code exists with a specific combination of the aforementioned criteria. The following
postings are made for this entry code:
○ Posting A: USD 500
○ Posting B: USD 800
○ Posting C: USD 900
2. You want to enter a new reserves balance of USD 2000 and create the corresponding balance posting.
3. You generate the account for this balance posting.
4. When it generates the account, the system calculates the total amounts from posting A, posting B, and
posting C (= USD 2300), compares this total with the amount entered for the balance posting (= USD
2000) and posts the difference in the generated account (= - USD 300).
12.3.12 Bordereau with Target Balance
Use
You can use this function to enter a target balance in the bordereau. If you want to use this function, you have
to enter the posting in one currency.
Prerequisites
If you are using more than one currency, you must either create one bordereau for each currency or delete the
target balance.
Features
You can enter a target balance in Basic System and Risk Manager bordereaux. The system compares the target
balance with a reference balance and calculates a difference amount. The reference balance corresponds to

the total postings entered in Customizing for calculation base 4 (for example, cash balance). You can generate
accounts at any time. However, you can release these accounts or transfer them to Basic System only when the
difference amount is zero.
12.3.13 Bordereau Creation: Customizing
Before you can use the target balance you have to specify the reference balance in Customizing. You use the
Customizing activity Edit Defaults for Accounting to do this.
You find this Customizing activity under FS-RI Reinsurance Basic System Default Values . You use
calculation base 4 to specify the reference balance for the target balance function. For more information, see
Bordereau with Target Balance [page 706].
12.4 Extension Service
Use
You can use the Extension Service to add your own data fields to the database tables delivered with the system,
and to use this data in applications.
You use the Extension Service to define risk classes in Risk Manager.
For more information about the use of the Extension Service for this purpose, see Class Model with Risk
Classes [page 61].
Integration
To incorporate extension fields, you must use the Extension Service to define and generate suitable extensions,
extension fields, and extension views.
You can only apply the Extension Service to tables that have previously been defined as extendable. Each of
these tables is assigned to an application.
You can add a maximum of one extension to each extendable table.
Features
You can create extension tables that either contain additional attributes or additional data records relating to
these database tables. You also define the fields for these extension tables in the Extension Services.
When you generate extensions, the system generates the corresponding ABAP Dictionary objects, functions,
and screens automatically, and incorporates them in the corresponding application.

You can also categorize extensions as business views by grouping certain fields in an extension table into one
view. The user can then select this view in the corresponding application and enter the data on a separate tab
page.
12.4.1 Extendable Applications and Tables
Definition
Extendable applications form the basis for the Extension Service. You must define and describe extendable
applications in the Customizing setup delivered with the system before you can use them. Here, you can
specify whether the application supports msg.ProductManager (msg.PM) and whether it is based on the Rapid
Development Framework (RDF). For RDF applications, you see the application number, otherwise you see the
program name. Extendable tables are the extendable entities of the Extension Service. They describe
extendable database tables that are assigned to an application. Both the extendable tables and the
applications are described in the Customizing delivered with the system. This is general information relating to
the generation logic.
Use
You select the extendable application and table in the initial dialog for the Extension Service.
12.4.2 Extension
Definition
Each extension is assigned to an extendable table.
Structure
FS-RI extensions distinguish between the relationship categories 1:1 and 1:N. In the case of a 1:N relationship,
the system displays the defined extension fields in a table control. The fields for 1:1 extensions appear in
normal entry fields. You can assign fields to more than one extension. However, you cannot add the same field
to two extension tables with the same type of relationship (1:1 or 1:N) within an application. At present, the
system can create a maximum of 4 extensions per extendable table, regardless of the relationship category.
The creation of a new extension involves creating the extension table and the assigned extension fields.

12.4.2.1 Creating Extensions
Prerequisites
You have assigned each extension to an extendable table, which is in turn assigned to an extendable
application. Note that a maximum of one extension is allowed for each extendable table (regardless of the
relationship category).
Context
The creation of extensions is restricted to defining extension tables and assigning extension fields.
The extension fields of an extension with the relationship category 1:1 are displayed as normal entry fields.
Fields from 1:N extensions appear in a table control.
Procedure
1. Start the dialog for creating a new extension by clicking the Extensions folder in the context menu with the
secondary mouse button.
2. Enter the relevant data in the dialog box and confirm your entries.
3. Make the appropriate entries on the tab pages and save the extension.
12.4.2.2 Changing Field Selections
Prerequisites
The system allows you to assign only fields that have not yet been assigned to an extension with the same
relationship category.
Context
You use this procedure to assign extension fields that have been defined for the respective application category
to the extension tables. Note that you can only add extension fields, but not delete them.

Procedure
1. On the Table Fields tab page in the extension dialog, choose .
2. Select the fields you want to add, and choose .
12.4.2.3 Fields
Definition
You can define fields for each application category. They combine both the domain and data element
characteristics of the SAP system and offer the option of processing attributes in table maintenance.
Use
An extension field is always assigned to an extension table. However, the attributes of a field are not dependent
on the table, and a defined individually for each field.
Structure
To edit the extension fields, choose the Maintain Fields pushbutton at extension level in the Extension Service.
You open a field for editing by double-clicking the relevant node in the tree or by choosing Edit in the context
menu.
The Data Type Definition tab page contains the domain attributes. Some fields can only be processed when a
new field is created and may not be subsequently changed.
The Field Type Definition tab page contains the data element attributes. Some fields can only be processed
when a new field is created and may not be subsequently changed.
The Field Label tab page also contains information relating to data element attributes. This is needed to display
the field on the interface. All the field labels are required entries. The system determines the length in each
case, but you can also change it manually.
On the Currency/Quantity Fields tab page you can define reference fields in database tables for certain data
types. These are used to convert values automatically when the unit is changed.

12.4.2.4 Views
Definition
Business views allow you to incorporate any number of extension fields from an extension into an application,
independently of the company code and client.
In the application, the user later has the choice of suitable extension views.
Business views give you the option of displaying several extensions from the extendable table. You do this by
given the views for the respective extension the same name.
Use
You use views to maintain extensions across clients and company codes.
They also enable you to use several extensions at the same time within one application.
12.4.2.4.1 Creating Extension Views
Context
You use this procedure to create extension views for an extension to support specific business requirements.
You can use more than one extension in an application. To do so, you must assign the same view name to the
views of the respective extensions.
Procedure
1. Choose Create in the context menu of the Extension Views folder.

2. Make the necessary entries.
3. Choose to save your entries.

12.4.2.4.2 Changing Field Selections
Prerequisites
The extension must already have been generated successfully.
Context
You use this procedure to add or change fields for the extension views. You can create up to five views, since a
maximum of five extension tables can be created for an extendable table. If you want to display two views from
different extension tables on the same tab page, you must assign them to the same company code and give
them the same name.
Procedure
1. To edit a view, double-click the relevant node in the tree, or choose Edit View in the context menu.
2. To assign fields from the extension tables to the selected view, choose Change Field Selection.
3. On the Fields tab page, specify whether the field being displayed should be a required entry field.
Results
All views that are assigned indirectly to the same extendable table, and which have the same name, appear on
the tab page in the corresponding application.
12.4.2.5 Generation of an Extension
Use
You use this function to generate and activate a single extension. You must execute the generation run
individually for each extension you create.

Features
Warnings
Before you generate an extension, you should be aware of the following:
 Caution
When you generate a new extension, the system overwrites all the objects created by the generator (in the
package /MSG/E_CUSTOMER for application type 2). As a result, you must edit the corresponding data after
each generation run (this does not apply to BAdI implementations and specific changes to screens).
 Caution
Once extensions have been generated, they cannot be deleted or changed. You should therefore have a
clear idea of the extensions you need and the corresponding data types and fields they should contain.
Logging
The system logs each generation run. If an error occurs, the system displays the log window automatically after
completion or cancellation of the generation run.
To call the log details, choose .
To save the log, choose .
To display an overview of all the objects and their generation and activation status, choose .
Activities
When you choose at extension level, the system does the following:
1. It checks whether the objects to be generated have already been assigned to a transport request. If this is
not the case, you are prompted to assign or create a request.
 Note
You should always use a single transport request for transporting Extension Service components. This
ensures data consistency in the target system.
2. It checks whether foreign key relationships have been specified for the fields in an extension. If this is the
case, a dialog box prompts you to define a foreign key relationship according to the ABAP Dictionary. For
more information about foreign key relationships and possible checks, see the SAP system
documentation.
3. It checks whether the Extension Service contains data fields that use a value list with a hierarchical
structure. If this is the case, a dialog box prompts you to define the type of foreign key relationship. Use one
of the following as a constant for the check table field HierClass:
○ CoB (class of business)
○ LoB (line of business)

○ YRV1 (area)
4. It automatically incorporates all the objects generated by the Extension Service into the SAP transport
system via a transport request.
12.4.2.5.1 Check Generated Extensions
We recommend that you check each extension after every generation run.
Checking a Single Extension
You can check the status of an extension on the Attributes tab page at extension level. In order to use the
extension in conjunction with business views in an application, you must set both the table and the subscreen
to Active.
Overview of Extensions
At extension level you can call a list of all the extensions and check the status of the objects in the system using
the Generation Status pushbutton.
12.4.3 Transport/Distribution to Other Systems
Use
To use Extension Service enhancements in other systems (as opposed to the system in which the extension
was developed), you must transport the extensions.
Features
Joint Transport Request
We recommend that you bundle all the activities for the extension service definition in a joint transport request
(this is backed up by the Extension Service dialog). After the generation run, all the objects and Customizing
entries generated by the Extension Service are contained in this transport request. When you release and
transport this request, all the extensions contained in the request are available in the target system.
Transport of Individual Extensions
If you want to transport one or more specific extensions, you must release the current Extension Service
request in order to get a new request. In the Customizing dialog at extension level, you can then add all the

generated objects for the required extensions to a new request using the Transport pushbutton. Since you have
already released the old request, the system prompts you to create a new one, which you can then release and
transport. In addition to the generated objects, the system also transports all the Customizing entries with this
transport request.
Transported Objects
The procedures described above add the following objects and table entries to the Extension Service request:
● All the generated Extension Service objects (BAdI, tables, data elements, domains, structures, function
groups and modules, programs, and includes)
● BAPI structures and, if required, the ALE layer (confirm dialog box if needed)
● Customizing entries in the Extension Service dialog (fields, extensions, and views)
Internal system table entries in tables /MSG/RHIST_TAB, /MSG/0_TAB_REL, /MSG/0_TABELLEN, /MSG/

0_RELATION, /MSG/0_ATTIRBC.
Result
When you transport and import the request to the respective target system, the system generates all the
necessary objects in the package /MSG/E_CUSTOMER (application type 2). FS-RI releases and support
packages do NOT contain any generated objects. Depending on the type of extension, you may need to run
additional conversion programs to ensure that the Extension Service functions properly after installation of the
new release or support package.
12.4.4 Translation
To make the components of the Extension Services available in several languages, you can translate them using
the following transactions:
● /MSG/R_S_EXTTABLE (translate extensions)

● /MSG/R_S_FIELD (translate extension fields)
● /MSG/R_S_EXTENSGR (translate extension views)
● /MSG/R_S_DOMVALUE (translate fixed values for domains)
These transactions have also been incorporated into the Implementation Guide for Customizing.
12.4.5 BAPI and ALE Layer
Definition
The extensions available within the Extension Service are mapped to the ALE layer of the system via separate
structures. Each extension for a table relating to a business object has its own structure for the ALE layer. In
addition to the primary keys, this structure contains all the fields you have created for this table in the
Extension Service.

Use
The ALE layer definition delivered with the FS-RI system does not contain any customer-specific Extension
Service fields. The service report /MSG/R_S_EXTSRVC_FILL_BAPI is available for adding these fields to the
ALE layer.
Integration
If you set the “Generate ALE Layer” checkbox, you can compare the ALE layer for all FS-RI business objects in
the system with the definition status of the Extension Service. The system displays a log with all the changes
that have been made.
You should never make any manual changes to the ALE layer definition in conjunction with the Extension
Service.
The system runs this program as an XPRA program automatically when you install the FS-RI solution. You
should therefore only run it if you are experiencing problems with the ALE layer and the Extension Service
definitions.
12.4.6 Business Add-In (BAdI)
Definition
A Business Add-In (BAdI) is a way of incorporating customer-specific implementation logic into an existing
application. If you use the Extension Service, you can use BAdIs to incorporate the data defined in the
Extension Service fields into the flow logic manually.
Use
BAdIs are located in certain positions on the Extension Service screen. For example, you can define default
values for the fields on an Extension Service screen for an application component. You can also change the field
attributes, allowing you to hide certain fields, or lock them for input. The system can also check the values
entered by the user, and return appropriate messages.
You therefore use BAdIs to change the flow logic of the screen for the respective extension. One BAdI exists for
each application. For each extension in the Extension Service, this BAdI may contain up to six methods, which
you can use to program changes in the respective screen.
In order to be able to use the BAdIs for the Extension Service, you must create your own implementation-
specific implementation.

Structure
The Extension Service BAdIs may contain the following methods.
Methods for Extension Service BAdIs
Method Call Event
*PAI_FIELD_EXIT In PAI (in CHAIN)
*PBO_FIELD_EXIT In PBO (for 1:N, at the end of LOOP)
*PAI_TABLE_EXIT In PAI (for 1:N, after LOOP)
*PBO_TABLE_EXIT In PBO (for 1:N, after LOOP)
*POV_SCREEN_EXI In POV
*PBO_SCREEN_EXIT In PBO (for 1:N, at the end of LOOP)
12.4.6.1 Implementing Business Add-Ins
Context
You use this procedure to implement a Business Add-In (BAdI) for the Extension Service.
If the BAdI has been designed for multiple uses, several implementations may exist in one system but only one
can be active at any one time.
Procedure
1. Goto transaction SE19.
2. In the SAP menu, choose Tools ABAP Workbench Utilities Business Add-Ins Implementation .
3. Enter a name for the implementation and choose Create. You must create the BAdI in the customer
namespace, for example ZES_OBJ_BADI_IMPL.
4. A dialog box appears. Enter the name of the BAdI definition for which you want to create the
implementation.
5. On the next screen, enter a short text describing the implementation.
6. On the Interface tab page, double-click the method you want to implement. The system asks you to enter a
package for the implementation. If the system also asks you if you want to save the changes to the
implementation, confirm with Yes. The Class Builder screen appears.

7. Enter the coding to implement the extension between the two existing commands METHOD and
ENDMETHOD.
8. Save your entries, and return to the BAdI implementation screen.
9. Choose Activate.
10. Transport the implementation to all the relevant systems.
11. After you have activated the implementation, the system applies it automatically when the application
program is executed.
Results
The activated implementation is available in all the systems to which you have transported it.
12.4.6.1.1 BAdI Method FIELD_EXIT_PAI
Use
The system calls this method in the PAI module after the user has entered data and triggered a function code.
This method allows you to check the validity of the values the user has entered and respond by returning a
message or changing the data.
Structure PS_ZSTRUKTUR is the interface parameter for the fields on the screen.
Example
The system checks the First Name field in both cases against a certain value. In the first case, the system
displays a message if the value matches. In the second case, the system overwrites the value in the “Last
Name” field with a value.
METHOD /msg/if_ex_e_m_es_object~nobj01_2_pai_field_exit.
IF ps_zstruktur-vorname = 'Hans'.
MESSAGE i001.
ENDIF.
IF ps_zstruktur-vorname = 'Hermann'.
ps_zstruktur-nachname = 'Mustermann'.
ENDIF.
ENDMETHOD.

12.4.6.1.2 BAdI Method FIELD_EXIT_PBO
Use
The system calls this method before displaying the screen fields. It is used to fill the fields with default values.
Structure PS_ZSTRUKTUR is the interface parameter for the fields on the screen. In the case of a 1:N
extension, which is displayed on the screen as a table control, there is an additional parameter called
PV_CURRENT_LINE. This indicates which line of the table control is currently in structure PS_ZSTRUKTUR. You
can therefore call this parameter to control the line to be changed. This parameter is used for information
purposes only, and cannot be changed.
Example
Example 1: Default values for the fields “First Name” and “Last Name”
METHOD /msg/if_ex_e_m_es_object~nobj01_2_pbo_field_exit.
ps_zstruktur-vorname = 'Hermann'.
ENDMETHOD.
Example 2: As above, except that default values are only entered for the second line in the table control
METHOD /msg/if_ex_e_m_es_object~nobj01_2_pbo_field_exit.
IF pv_current_line = 2.
ps_zstruktur-vorname = 'Hermann'.
ENDIF.
ENDMETHOD.
12.4.6.1.3 BAdI Method FIELD_EXIT_POV
Use
The system calls this method at POV (PROCESS ON VALUE-REQUEST) after the user has called the input help.
The method allows you to set up input help manually for the user for the fields on the screen. The method is
called for both 1:1 and 1:N extensions. You can use the “Input Help” checkbox in the Customizing dialog at
extension level to specify the fields for which you want the system to generate a manual input help facility. In
the method you therefore have to query the field for which you want input help to be generated, since all the
fields use the same method.
The PV_FIELDNAME parameter tells the method for which field the input help is being requested.

Example
In the dialog box, the user calls the input help for the MC_PERCENTAGE field.
METHOD /msg/if_ex_ec_object~nobj01_2_pov_screen_exit .
TYPES: BEGIN OF lty_helpvalue,
low TYPE domvalue_l,
text TYPE val_text,
END OF lty_helpvalue.
DATA lt_fields TYPE TABLE OF help_value.

DATA ls_fields TYPE help_value.
DATA lt_werte TYPE TABLE OF lty_helpvalue.
DATA ls_werte TYPE lty_helpvalue.
DATA lv_key(40).
DATA lv_text(40).
REFRESH: lt_fields,
lt_werte.
* Einlesen der Festwerte

IF pv_fieldname CP '*MC_PERCENTAGE*'.
* Anzeigefelder im POPUP festlegen
ls_fields-tabname = 'DD07V'.
ls_fields-fieldname = 'DOMVALUE_L'.
ls_fields-selectflag = 'X'.
APPEND ls_fields TO lt_fields.
ls_fields-tabname = 'DD07V'.
ls_fields-fieldname = 'DDTEXT'.
ls_fields-selectflag = ''.
APPEND ls_fields TO lt_fields.
ls_werte-low = '15,00'.
ls_werte-text = 'Prozentsatz Nichtraucher'.
APPEND ls_werte TO lt_werte.
ls_werte-low = '75,00'.
ls_werte-text = 'Prozentsatz Raucher'.
APPEND ls_werte TO lt_werte.
ENDIF.
* Wertehilfe darstellen.
CALL FUNCTION '/MSG/R_S_F4_POPUP'
EXPORTING
titleline = text-p04
repid = sy-repid
dynnr = sy-dynnr
update_screen = 'X'
result_fieldname = pv_fieldname
index = sy-stepl
mode = '02'
update_disabled_fields = ''
IMPORTING
result_value = lv_key
text_value = lv_text
TABLES
listtab = lt_fields
valtab = lt_werte
EXCEPTIONS
no_values = 1
OTHERS = 2.
IF NOT sy-subrc = 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.

ENDMETHOD.
12.4.6.1.4 BAdI Method SCREEN_EXIT_PBO
Use
The system calls this method for each dialog field at PBO. The method allows the user to make user-specific
changes to individual fields.
Structure PS_SCREEN is the interface to the attributes of the respective field.
In the case of a 1:N extension, which is displayed on the screen as a table control, there is an additional
parameter called PV_CURRENT_LINE. This indicates which line of the table control is currently in structure
PS_ZSTRUKTUR. You can therefore call this parameter to control the line to be changed. This parameter is
used for information purposes only, and cannot be changed.
Example
Example 1: Hide a field
METHOD /msg/if_ex_e_m_es_object~nobj01_2_pbo_screen_exit.
IF ps_screen-name CP '*VORNAME*'.
ps_screen-invisible = 0.
ENDIF.
ENDMETHOD.
Example 2: A field is hidden only in the first line of the table control
METHOD /msg/if_ex_e_m_es_object~nobj01_2_pbo_screen_exit.
IF pv_current_line = 1.
IF ps_screen-name CP '*VORNAME*'.
ps_screen-invisible = 0.
ENDIF.
ENDIF.
ENDMETHOD.
12.4.6.1.5 BAdI Method TABLE_EXIT_PAI
Use
The system calls this method in the PAI module after the user has entered data and triggered a function code.
This method allows you to check the validity of the values the user has entered in the entire table control and

respond by returning a message or changing the data. This method is available only for 1:N extensions. The
internal table PT_ZTABLE is the interface parameter for the Z table of the screen.
Example
You want to check whether the total percentage share for the MC_PERCENTAGE field does not exceed 100%.
METHOD /msg/if_ex_ec_object~nobj11_2_pai_table_exit .
DATA lv_count TYPE i.
FIELD-SYMBOLS: <line> TYPE ANY.

FIELD-SYMBOLS <field> TYPE ANY.
lv_count = 0.
LOOP AT pt_ztable ASSIGNING <line>
* Field 'MC_PERCENTAGE' ins Feldsymbol einlesen
ASSIGN COMPONENT 'MC_PERCENTAGE' OF STRUCTURE <line> TO <field>
* Prozentsatz zwischen 0 und 100% einschränken
IF <field> LT 0 OR <field> GT 100.
MESSAGE 'Nicht zulaessiger Prozentsatz!' TYPE 'I'.
CLEAR
EXIT.
ENDIF.
* gesamten prozentualen Anteil ermitteln
* MESSAGE falls mehr als 100%
lv_count = lv_count + <field>
IF lv_count GT 100.
MESSAGE 'Gesamte Anteile mehr als 100%!' TYPE 'I'.
CLEAR <field>
EXIT.
ENDIF.
ENDLOOP.
ENDMETHOD.
12.4.6.1.6 BAdI Method TABLE_EXIT_PBO
Use
The system calls the method at PBO before it displays the screen. The method supplies the user with
information about the field contents before they are displayed on the screen. This method is available only for
the 1:N extension.
The internal table PT_ZTABLE is the interface parameter for the Z table of the screen.

Example
The system warns the user before the 100% share is exceeded, quoting the remaining percentage share.
METHOD /msg/if_ex_ec_object~nobj11_2_pbo_table_exit.
DATA lv_count(3) TYPE c.
DATA lv_count_str(18) TYPE c.
FIELD-SYMBOLS: <line> TYPE ANY.

FIELD-SYMBOLS <field> TYPE ANY.
lv_count = 0.
LOOP AT pt_ztable ASSIGNING <line>.
* Field 'MC_PERCENTAGE' ins Feldsymbol einlesen
ASSIGN COMPONENT 'MC_PERCENTAGE' OF STRUCTURE <line> TO <field>.
* Prozentuale Anteile addieren
lv_count = lv_count + <field>.
ENDLOOP.
* Den Benutzer mit der Restanteilhoehe von der Ueberschreitung
* des 100%-en Prozentsatz warnen!
* Restanteil ermitteln:
lv_count = 100 - lv_count.
MOVE lv_count TO lv_count_str.
CONCATENATE 'Rest.%-Anteil=' lv_count_str '%' INTO lv_count_str.
MESSAGE lv_count_str TYPE 'I'.
ENDMETHOD.
12.5 External References
Use
You can assign an additional ID to an object.
This ID can, for example, be the ID for a reinsurance treaty that was used in a system before the introduction of
the FS-RI solution. If you create this ID in the FS-RI treaty, you can see the treaty in the legacy system to which
the FS-RI treaty corresponds. As another example, you can create the ID for a business partner's account as an
external reference. This means that you can find the account quickly in the FS-RI system when you receive
correspondence from this business partner.
You can create external references at treaty, section, and share level in a treaty, at policy header, policy section,
value insured, premium, and participation level in Risk Manager, and in loss and group management, as well as
in the account and Object Manager.
External references are usually set during migration projects or when data is imported using interfaces.

Integration
External references are also used on the P2R interface [page 563] to create the reference between objects in
the primary insurance system and objects in the FS-RI system.
Features
You must assign each external reference to an external reference category. The external reference category
determines the external entity to which the reference refers.
Examples of external reference categories include:
● ID for a business partner's account

● ID for a policy in the primary insurance system that is to be reinsured
● Each external reference category is assigned to the area of a specific FS-RI object type and can be used in
these objects only. External reference categories can be assigned to the following areas.
Basic System Risk Manager
90 Account 1 Policy
100 Treaty 2 Policy Section
101 In-Force Business 3 Coverage
102 Share 4 Value Insured
200 Loss 5 Premium
6 Group
7 Object
8 Participation
You can use a checkbox in Customizing for external reference categories to control the extent to which the
external references belonging to a category must be unique.
Activities
Before you can work with external references in a migration project or when configuring an interface, you must
define the external reference categories that you want to import.
Different views of the table of external reference categories are available in Customizing. These views are
filtered according to the external reference categories relevant for the Customizing area. However, you can use
any of these Customizing settings to create external reference categories.

The following Customizing settings are available in external Customizing for FS-RI Reinsurance:
FS-RI Risk Manager (Non-Life) Policy/Certificate Administration Edit External Reference Categories for
Policies
● FS-RI Risk Manager (Non-Life) Group Management Edit External Reference Categories for Groups
● Basic System Accounting Edit External Reference Categories for Accounts
● Basic System Loss Edit External Reference Categories for the Loss
In addition to these external references, you can enter a customer reference at participation level. Customer
references are freely definable entries, do not require a reference category, and are not subject to a uniqueness
check.
 Example
Manual Use
● Requirement
Your cedent delivers their accounts in a specific file format. A unique account number is printed on
each account. The administrator in your company creates these accounts as FS-RI accounts manually.
You want to be able to find the original document for your FS-RI account at any time.
● Solution
When the administrator creates the account in the FS-RI system, they save the number of the original
account in the FS-RI account as an external reference with the category ABR-NR ZEDENT.
You have created the external reference category ABR-NR ZEDENT with the area 90 (account) in
Customizing for this purpose.
Migration
● Requirement
You are replacing your current reinsurance software system with the FS-RI solution and are migrating
all the treaties from the legacy system to the FS-RI system. You are using internal number assignment
in the FS-RI system, which means that the treaties are assigned different IDs than in the legacy system.
However, you do not want to lose the reference to the treaty in the legacy system.
● Solution
You migrate the treaty ID in the legacy system to the treaty in the FS-RI system as an external
reference.
You have created the external reference category VTG-ID Altsystem with the area “Treaty” for this
purpose.
12.6 Organizational Plan
Use
You can use the Organizational Plan component to comprehensively display and edit your company’s current
organizational and reporting structures and to flexibly plan and model HR-relevant changes, for example during
(re)engineering. You can display and edit organizational structures hierarchically or as a matrix. The object-
oriented design of Organizational Management allows you to display organizational units, positions and their

holders and tasks in an organizational plan and to edit this plan or individual objects according to your
requirements. This gives you an overview of the current status of your organizational and reporting structures
and enables you to analyze historical data at any time. In addition, you can plan and model future scenarios. For
more information about Organizational Management and the objects involved, see SAP Online Help.
Features
The following different process steps are used to create an organizational plan: Map the organizational
structure:
An organizational plan is described by the organizational units that exist in the company. For the most part,
these organizational units are linked together in a hierarchical structure that simultaneously reflects the
company’s reporting lines. However, you can also create organizational units that are not integrated into any
structure. To create a new organizational plan, you must first create a root organizational unit. This is the
highest-level unit of an organizational structure (for example, the executive board) and is the starting point for
building the organizational structure from the top down. Create staff assignments
: Staff assignments are created for every organizational unit. First positions are created, which are assigned to
the various organizational units. An advantage of the organizational model, in which your organizational
structure is displayed, is that a position is based on a job that describes it. This means that the position adopts
the task description for the job, reducing your project outlay considerably. Therefore, you need to describe the
position of only those, more specific, tasks that go beyond the ones derived. A job is an area of activity
described by tasks and requirements. It occurs only once in a company, for example, a secretary or
programmer. You create these when your organizational plan requires jobs that do not yet exist in your job
index. Otherwise, you create positions first because the underlying jobs, from which you derive positions, are
automatically displayed. Employees
: You must assign occupants to the positions. This enables you to determine which employee or system user
occupies a position. You can use this assignment to enter system users as processors of work items for
workflow applications; you can do this either directly or indirectly, through a link to employees. When you are
entering data, you can also identify positions as managers of an organizational unit (chief positions).
12.6.1 Change Organizational Structure Initial Screen
On this screen you can maintain the organizational plan. You call the basic functions using the following menu
paths: Create: FS-RI: Reinsurance Master Data Organizational Plan Create ; change: FS-RI:
Reinsurance Master Data Organizational Plan Change ; display: FS-RI: Reinsurance Master Data
Organizational Plan Display ; structural graphic: FS-RI: Reinsurance Master Data Organizational Plan
Structural Graphic ; adjust usage: FS-RI: Reinsurance Master Data Organizational Plan Adjust
Usage . These fields and functions correspond to the standard SAP system; see SAP Online Help. You can
access the initial screen from the standard SAP menu by choosing: Tools Business Workflow
Organizational Plan .

12.7 Responsibilities
Definition
The authorization concept enables you to distribute authorizations and tasks in the FS-RI system to individual
employees or departments, according to your company structure. This applies, in particular, to the
responsibilities for business objects, such as a treaty.
Use
The responsibilities and authorizations for certain functions depend on the roles assigned to an employee or
position. For example, depending on the role, an employee can be assigned a certain responsibility for the
treaty in the treaty header. You can also specify this in Customizing under Maintain Role Responsibilities for
Treaty.
Integration
If you are using SAP Organizational Management (PD-ORG), you can use organizational management and
define corresponding competences to assign the authorizations in the FS-RI system to organizational units and
positions defined in PD-ORG. If you do not have this module, you can use business partner roles to assign
authorizations to individual employees who are specified as business partners in the FS-RI system. These
employees must be assigned a position and an organizational unit in the business partner if they have a role
that includes a responsibility for treaty or loss.
12.7.1 Method Using BP Roles (Without Organizational

Management)
Definition
In Customizing in the FS-RI system you can define as many different responsibilities as you want for each
treaty or loss business object. You do this by defining roles that reflect the desired responsibility, and then by
creating business partners who can assume this role. You maintain these business partners using an FS-RI
enhancement of the SAP Business Partner functions. Each business partner usually represents a company
employee. This employee assumes a responsibility (defined by the business partner role) in relation to the
business object.

Use
The FS-RI system uses these responsibilities in various places to verify authorizations. A responsibility
(expressed by exercising a role in relation to a business object) gives you the authorization to perform certain
actions.
Integration
If you use this method, you can define corresponding FS-RI organizational units and positions in Customizing
for FS-RI Reinsurance under Basic System -> Basic Settings -> Organizational Management.
12.7.1.1 Creation of a Business Object
When you create a business object (such as a treaty or loss), you must assign the business partners for the
respective roles in the Responsibilities section.
The system displays only the roles that have been created for the business object in Customizing.
You can only select a partner that has been created as a business partner in the corresponding role. On the
Reinsurance tab page in the business partner maintenance screen, you can assign the business partner to an
FS-RI organizational unit and position that has been defined in Customizing.
When you maintain authorizations, you can then assign authorizations for certain FS-RI organizational units
and positions to specific authorization objects (such as treaty, loss, or account).
12.7.1.2 Display or Change a Business Object
When you display or change a business object, the system checks whether the AUTH_VTG and AUTH_SDN
checkboxes have been set.
Authorization Check If AUTH_VTG Checkbox Is Set
If the AUTH_VTG checkbox has been set, the system first determines the person responsible for the treaty, and
then the partner assigned to this role. It selects the department and position of the partner (if available), and
uses them as fields in the authorization check for authorization object YRVB_VTG. If the system is unable to
determine the department or position, dummy values are entered in the corresponding authorization object
fields. This can be the case if the treaty is new, if the role assignment is missing in an existing treaty, or if no
department or position was assigned to the partner. If these fields are filled with dummy values, the
authorization check is only applied to the remaining fields in authorization object YRVB_VTG. The check is then
performed for the current user based on the current mode (create, change, display treaty), treaty number, and
company code.

Authorization Check If AUTH_VTG Checkbox Is Not Set
If the AUTH_VTG checkbox has not been set, the system does not determine the person responsible for the
treaty, and as such does not determine the department and position. In this case, the department and position
fields in authorization object YRVB_VTG are filled with dummy values, meaning that no authorization check is
applied to these fields. The authorization check is only applied to the remaining fields in authorization object
YRVB_VTG. The check is then performed for the current user based on the current mode (create, change,
display treaty), treaty number, and company code.
The same flow logic applies for losses (AUTH_SDN checkbox).
12.7.1.3 Configuration
The following sections explain how to define your own roles and use them in the FS-RI system.
12.7.1.3.1 Defining Roles
You can define your own roles using transaction BUSD.
When you create a new role, the following fields are mandatory:
● Business partner role

● Name
● Title
● Differentiation type
You can also enter the business partner category, which can be an organization, person, or group.
12.7.1.3.2 Configuring Roles for Objects
You assign the roles to business objects in Customizing:
Assignments for treaties: FS-RI Reinsurance Basic System Treaty Edit Responsibilities for the Treaty
Assignments for losses: FS-RI Reinsurance Basic System Loss Edit Responsibilities for the Loss
12.7.1.3.2.1 Loss
The following fields are relevant when you create a new responsibility for losses.
Role
This is the role that a business partner can assume in relation to a treaty or loss.

Mandatory for Loss
If you set this checkbox, this role is mandatory when a new loss is created.
Authorization Loss 1
If you set this checkbox, this role is used in the authorization check for a loss.
Authorization Loss 2
If you set this checkbox, this role is used in the authorization check for creating or changing loss accounts.
Active Loss
This indicates whether the role has been activated for loss management.
RI Role
This is a role that is assigned to the role category.
12.7.1.3.2.2 Treaty
The following fields are relevant when you create a new responsibility for treaties.
Role
This is the role that a business partner can assume in relation to a treaty or loss.
Mandatory for Treaty
The role is mandatory when a new treaty is created and is entered automatically in the table control for
responsibilities in the treaty header data. The user must assign a partner to the role.
Authorization Check for Treaty
This indicates whether an authorization check is required for treaty management. You can only set this
checkbox for a maximum of one mandatory role for the treaty.
Active Treaty
This indicates whether the role has been activated for treaty management.
RI Role
This is a role that is assigned to the role category.
12.7.2 Method Using Competences and Organizational

Management
Definition
A competence is a type of responsibility (for example, "Responsible for Treaty" or "Responsible for Account")
for FS-RI business objects (such as treaty or loss). You can assign competences to individual employees, or to
entire departments.

When you create or change a business object, you assign the possible competences directly to a node in SAP
Organizational Management (PD-ORG) (organizational unit, position).
Use
This structural authorization enables you to perform authorization checks based on where the user is assigned
within the organizational structure.
You define the competences in Customizing, where you can also specify whether they are relevant for the
structural checks. You can also define competences purely for information purposes without affecting
authorizations.
 Example
Example: A certain set of treaties is only allowed to be processed by Department A, while a different set of
treaties is only allowed to be processed by Department B.
Advantages
● The data to be protected can be assigned to time-dependent, hierarchical structures.

● You can assign access authorizations (change, display) flexibly to certain subareas or units.
● If changes are made to the structure, the authorizations are adjusted dynamically. This reduces the
maintenance when the structure is modified. For example, if department 123 is split into the subareas 123.1
and 123.2. The structural authorization automatically gives the manager of department 123 access to the
objects in the new areas.
● You can assign rights for superiors and substitutes.
● The responsibilities are independent of individuals – if an employee is assigned to a new position in the
organizational structure, this employee automatically loses the responsibility and rights for the business
objects associated with the old position, which are tied to the structure node.
Other Uses
The assigned organizational units and positions are also stored in the accounts and can be used for
evaluations.
They can also be used to find out which employees are involved in processing a business object.
Integration
You can activate competences and structural authorization checks in Customizing for FS-RI Reinsurance under
Basic System Basic Settings Organizational Management Choose Organizational Plan . You do this by
deactivating the “Dept/Pos.” checkbox and entering an organizational unit as the root object.
You define the competences in Customizing. In the application you then assign the processing steps or
situations that are subject to authorization checks.
The structural authorizations are also defined in Customizing. You can either do this within the component BC-
BMT-OM (Organizational Management) or in Customizing for FS-RI Reinsurance under Basic System Basic
Settings Authorizations Structural Authorizations .

For more information about using structural authorizations, see the documentation for “Authorizations in
mySAP HR” in SAP Library or on SAP Service Marketplace.
12.7.2.1 Configuration
This section covers the activation of the structural authorization, the assignment of users to structural profiles,
the creation of evaluation paths and structural profiles, and the definition of competences.
12.7.2.1.1 Activation of the Structural Authorization
In Customizing for FS-RI Reinsurance under Basic System Basic Settings Organizational Management
Choose Organizational Plan (table /MSG/RORGZUO), you use the checkbox for structural authorizations to
indicate whether you want to apply structural authorizations or the method used previously. If you deselect the
Dept/Pos. checkbox, the system uses the structural authorizations from SAP Organizational Management (PD-
ORG). If you switch from the business partner method for handling responsibilities to the method using
competences and structural authorizations you can migrate the business objects gradually. The data is
migrated only in change mode. In display mode, the data only appears to have been migrated the data is
migrated but not saved. This allows you to switch from one authorization concept to another without
interruption.
12.7.2.1.2 Assignment of Users to Structural Profiles
To activate individuals in the organizational structure, you first need to assign them structural profiles in
Customizing. The profile restricts the authorizations for that employee to those that are relevant for the set of
tasks. You assign these profiles in Customizing for Personnel Management under Organizational
Management Basic Settings Authorization Management Structural Authorization Assign Structural
Authorization . In this Customizing activity you enter all the users and assign the corresponding profile to
each one. Note: Users that have not been mentioned specifically are treated in the same way as the user "SAP".
12.7.2.1.3 Creation of Evaluation Paths and Structural Profiles
Creating structural profiles: You can define authorizations for the following areas: plan versions, object
categories, object IDs. You can also use the following parameters and functions when you define authorization
profiles. Evaluation paths: If you specify a particular evaluation path, the user can access only objects along
this evaluation path. If you use an evaluation path, you must make an entry in the "Object ID" field. Status
vector: You use this field to restrict user access to objects for which the relationship infotype has a certain
status (such as "Planned" or "Active"). Display depth: The display depth determines the hierarchy level up to
which the user has access in a structure. Period: You can use this parameter to define a profile for a certain
validity period. For example, if you choose entry D (current day), the structural authorization applies only to the

structure valid on the current day. If you do not specify a date, there is no restriction on the validity period of
structures. Function module: You can use a function module to determine the root object dynamically at
runtime. In this case, you are not allowed to specify an object ID, but are required to enter a plan version and
object type. The advantage of using function modules is that you only need to define one authorization profile.
At runtime the system determines the root objects dynamically and creates the user-specific profile in each
case. There are two standard function modules. The first is RH_GET_MANAGER_ASSIGNMENT (determine
organizational units for managers). If you use this function module, the root object is taken to be the
organizational unit to which the respective user is assigned via the plan version and the relationship A012 (is
manager of). This function module works by key date. When it establishes the root object, it determines only
the organizational units to which a user is assigned as "Manager" on the specified date or during the specified
period. The second is RH_GET_ORG_ASSIGNMENT (organizational assignment). If you use this function
module, the root object is taken to be the organizational unit to which the respective user is assigned. In
addition, you can define profiles that contain maintenance authorization. To do this, you select the processing
type for maintenance ("Maint." field). This allows the execution of function codes that have been flagged for
maintenance in table T77FC. The overall authorization is determined on the basis of the core authorization and
the restrictions defined in the structural authorization. Evaluation paths are used to select objects for
evaluations. You select an evaluation path, and the system evaluates the structure along this evaluation path.
The system takes only the objects it finds via this evaluation path into account. 1. You create evaluation paths in
Customizing under Personnel Management Organizational Management Basic Settings Maintain
Evaluation Paths . 2. The Evaluation Paths: Overview screen appears. Enter a name for the evaluation path,
with a maximum of 8 alphanumeric characters. Branch to the subview Evaluation Path (Individual
Maintenance). Enter the relationship chain for the evaluation. Use report RHRELAT0 to determine the
permitted relationships for an object type. If you want to use an evaluation path in a view, note the following:
You need to define the evaluation path in such a way that the relationship chain always begins with a user
(object type US in Organizational Management), and ends with an organizational unit, position, or user. When
you define the evaluation path, use the Skip checkbox wherever appropriate (see below). This helps to keep the
volume of evaluation results down to a manageable size. If you want to use an evaluation path in a rule for agent
determination, note the following: You must define the evaluation path in such a way that the relationship chain
starts with the Organization Management object type, which you can transfer in the rule container. If you set
the Skip checkbox, this part of the evaluation path is taken into account, but not displayed. Before you create
new evaluation paths, check the existing evaluation paths in the standard system. The view for maintaining
individual evaluation paths contains the following fields: No.: sequence number. Object Type: This field contains
an object type key comprising one or two characters, such as "S" for a position, "Q" for a qualification, or "E" for
a business event. Relationship Specification (A/B): This field contains a key for the relationship type. PD
supports two relationship types, bottom-up and top-down. Priority: This is an optional field that determines the
sequence of the objects in Simple Maintenance and in the Structural Graphics. Type of Related Object: This
field contains a one-character or two-character key for a certain object type, such as "S" for a position, "Q" for a
qualification, or "E" for a business event. You can use this checkbox to specify that a certain relationship within
an evaluation path should be considered in the evaluation, but not displayed.
12.7.2.1.4 Defining Competences
If you use the structural authorizations, you no longer need the business partner roles for responsibilities. Even
if you create the company employees as business partners, it is sufficient to create them in the role of
Employee. Instead, the new method uses competences to determine the responsibilities and authorizations for
business objects.

Examples of competences include Responsible for Loss Processing or Responsible for Accounts
Relating to this Treaty.
The FS-RI authorization checks are applied to all the competences that have been defined as relevant for
certain authorization situations in Customizing:
FS-RI Reinsurance Basic System Basic Settings Authorizations Edit Competences
FS-RI Reinsurance Basic System Basic Settings Authorizations Assign Competences to Modules
For a more detailed description, see the documentation for each Customizing activity.
12.7.2.2 Display or Change a Business Object
On the initial screen for a transaction (such as "Change Treaty), the system displays only the objects for which
the user has display authorization.
As soon as the user calls a specific business object, the system determines the relevant node in the
organizational structure and checks whether the user has authorization for the respective processing mode.
In doing so, the system "translates" the processing mode (display or change) into the HR function code
(display or maintenance).
12.7.2.3 Creation of a Business Object
When you create a business object, you need to assign the relevant nodes in the organizational structure to the
respective competences (such as "responsible for treaty", "responsible for account") in the Responsibilities
section.
Using the input help, you can display a tree structure with the organizational units for which you are authorized
(processing mode "Create > HR Maintenance Authorization") and then select the relevant node for the
competence. Once you have made the selection, the system displays the object type and the object ID.
Depending on the how the competences have been defined in Customizing, the system either allows you to
only assign nodes for which you have authorization, or nodes that are determined for the competence in
question.
In Customizing you also specify which competences the user is required to enter, and which are optional.

12.8 Business Warehouse Extractors
Definition
Extractors for master data and transaction data as well as for texts are available for the collection and transfer
of data from the FS-RI system to SAP Business Information Warehouse (BW). These extractors are found in
transaction SBIW. If you require additional extractors, you can create these in transaction SBIW.
Before you work with BW, you must set up the correct application component hierarchy.
More Information
For more information about the transfer of data to SAP Business Information Warehouse, see transaction
SBIW.
For more information about evaluations using SAP Business Information Warehouse, see the documentation
for this SAP module.
For more information about editing the application component hierarchy, see Editing Application Component
Hierarchy for BW [page 735].
12.8.1 Editing Application Component Hierarchy for BW
Transfer the application component hierarchy in transaction SBIW by choosing Data Transfer to the SAP
Business Information Warehouse Business Content DataSources Transfer Application Component
Hierarchy .
Switch to the transaction Postprocessing of DataSourcesEdit DataSources and Application Component

Hierarchy.
Create an application component hierarchy with the following structure:
-> SAP (already exists in the system)
-> -> FS-RI (Financial Services - Reinsurance)
-> -> -> FS-RI-B (Financial Services - Reinsurance - Basic System)
-> -> -> FS-RI-B-IO (Master Data - Reinsurance - Basic System)
-> -> -> FS-RI-RMN (Financial Services - Reinsurance - Risk Manager (Non-Life))
-> -> -> FS-RI-RMN-IO (Master Data - Reinsurance - Risk Manager (Non-Life))
For more information about the procedure, see the documentation for the transaction Edit DataSources and
Application Component Hierarchy.

12.8.2 Extractors for Basic System Master Data
12.8.3 Extractors for Basic System Texts
The extractors listed below enable the extraction of data fields from application tables in Basic System that
contain texts.
Extractor Name Application Table Read
/MSG/BWR_ABBRCHBEZ_TEXT /MSG/RABBRCHBEZ
/MSG/BWR_ABRFKTBEZ_TEXT /MSG/RABRFKTBEZ
/MSG/BWR_ABRMOD_BEZ_TEXT /MSG/RABRMOD_BEZ
/MSG/BWR_ABRPOSBEZ_TEXT /MSG/RABRPOSBEZ
/MSG/BWR_ABRSTATBEZ_TEXT /MSG/RABRSTATBEZ
/MSG/BWR_ACTIVBEZ_TEXT /MSG/RACTIVBEZ
/MSG/BWR_AEGRDSCBEZ_TEXT /MSG/RAEGRDSCBEZ
/MSG/BWR_AENDGRDBEZ_TEXT /MSG/RAENDGRDBEZ
/MSG/BWR_AGENBEZ_TEXT /MSG/RAGENBEZ
/MSG/BWR_AMLOSSBEZ_TEXT /MSG/RAMLOSSBEZ
/MSG/BWR_ANTTYPBEZ_TEXT /MSG/RANTTYPBEZ
/MSG/BWR_ANWENKZBEZ_TEXT /MSG/RANWENKZBEZ
/MSG/BWR_APBEZ_TEXT /MSG/RAPBEZ
/MSG/BWR_APPAREABEZ_TEXT /MSG/RAPPAREABEZ
/MSG/BWR_AUBEZ_TEXT /MSG/RAUBEZ
/MSG/BWR_AUTHBEZ_TEXT /MSG/RAUTHBEZ
/MSG/BWR_AUTHSITBEZ_TEXT /MSG/RAUTHSITBEZ
/MSG/BWR_BAUSTBEZ_TEXT /MSG/RBAUSTBEZ
/MSG/BWR_BEGRTYPBEZ_TEXT /MSG/RBEGRTYPBEZ
/MSG/BWR_BEREICHBEZ_TEXT /MSG/RBEREICHBEZ

/MSG/BWR_BETRBBEZ_TEXT /MSG/RBETRBBEZ
/MSG/BWR_BILJJKZBEZ_TEXT /MSG/RBILJJKZBEZ
/MSG/BWR_BILSTATBEZ_TEXT /MSG/RBILSTATBEZ
/MSG/BWR_BORSTATBEZ_TEXT /MSG/RBORSTATBEZ
/MSG/BWR_BPFKTBEZ_TEXT /MSG/RBPFKTBEZ
/MSG/BWR_BRBAUMBEZ_TEXT /MSG/RBRBAUMBEZ
/MSG/BWR_BRHIERBEZ_TEXT /MSG/RBRHIERBEZ
/MSG/BWR_BUCOARTBEZ_TEXT /MSG/RBUCOARTBEZ
/MSG/BWR_BUCOBEZ_TEXT /MSG/RBUCOBEZ
/MSG/BWR_BUCOCOLBEZ_TEXT /MSG/RBUCOCOLBEZ
/MSG/BWR_BUCOVZBEZ_TEXT /MSG/RBUCOVZBEZ
/MSG/BWR_BUZTRBBEZ_TEXT /MSG/RBUZTRBBEZ
/MSG/BWR_BUZTRBEZ_TEXT /MSG/RBUZTRBEZ
/MSG/BWR_BU_BEDBEZ_TEXT /MSG/RBU_BEDBEZ
/MSG/BWR_BWTYPBEZ_TEXT /MSG/RBWTYPBEZ
/MSG/BWR_B_KKDRUBEZ_TEXT /MSG/RB_KKDRUBEZ
/MSG/BWR_B_KKPOSTXT_TEXT /MSG/RB_KKPOSTXT
/MSG/BWR_B_KKTXTBEZ_TEXT /MSG/RB_KKTXTBEZ
/MSG/BWR_CALCMETBEZ_TEXT /MSG/RCALCMETBEZ
/MSG/BWR_COLUBEZ_TEXT /MSG/RCOLUBEZ
/MSG/BWR_CONDCLABEZ_TEXT /MSG/RCONDCLABEZ
/MSG/BWR_CONDTYPBEZ_TEXT /MSG/RCONDTYPBEZ
/MSG/BWR_CURTYPBEZ_TEXT /MSG/RCURTYPBEZ
/MSG/BWR_DATAMETBEZ_TEXT /MSG/RDATAMETBEZ
/MSG/BWR_DECKTYPBEZ_TEXT /MSG/RDECKTYPBEZ
/MSG/BWR_DEPHARTBEZ_TEXT /MSG/RDEPHARTBEZ

/MSG/BWR_DEPOARTBEZ_TEXT /MSG/RDEPOARTBEZ
/MSG/BWR_DUETYPEBEZ_TEXT /MSG/RDUETYPEBEZ
/MSG/BWR_EAKZBEZ_TEXT /MSG/REAKZBEZ
/MSG/BWR_EARCLOCBEZ_TEXT /MSG/REARCLOCBEZ
/MSG/BWR_EARCLOCP_TEXT /MSG/REARCLOCP
/MSG/BWR_EARCURBEZ_TEXT /MSG/REARCURBEZ
/MSG/BWR_EB_ARTBEZ_TEXT /MSG/REB_ARTBEZ
/MSG/BWR_EB_AZP_BEZ_TEXT /MSG/REB_AZP_BEZ
/MSG/BWR_EEVTMPBEZ_TEXT /MSG/REEVTMPBEZ
/MSG/BWR_EINBFRBEZ_TEXT /MSG/REINBFRBEZ
/MSG/BWR_ERWGEBBEZ_TEXT /MSG/RERWGEBBEZ
/MSG/BWR_FAS_CLSBEZ_TEXT /MSG/RFAS_CLSBEZ
/MSG/BWR_FELDGRPBEZ_TEXT /MSG/RFELDGRPBEZ
/MSG/BWR_FGABARTBEZ_TEXT /MSG/RFGABARTBEZ
/MSG/BWR_FGARTZPBEZ_TEXT /MSG/RFGARTZPBEZ
/MSG/BWR_FLDNAM_BEZ_TEXT /MSG/RFLDNAM_BEZ
/MSG/BWR_FMKRITBEZ_TEXT /MSG/RFMKRITBEZ
/MSG/BWR_FUEHTYPBEZ_TEXT /MSG/RFUEHTYPBEZ
/MSG/BWR_F_BGRBEZ_TEXT /MSG/RF_BGRBEZ
/MSG/BWR_F_SARTBEZ_TEXT /MSG/RF_SARTBEZ
/MSG/BWR_GARTBEZ_TEXT /MSG/RGARTBEZ
/MSG/BWR_GARTKZBEZ_TEXT /MSG/RGARTKZBEZ
/MSG/BWR_GBOVERBBEZ_TEXT /MSG/RGBOVERBBEZ
/MSG/BWR_GEBTYPBEZ_TEXT /MSG/RGEBTYPBEZ
/MSG/BWR_GEDBETRBEZ_TEXT /MSG/RGEDBETRBEZ
/MSG/BWR_GEFAHRBEZ_TEXT /MSG/RGEFAHRBEZ

/MSG/BWR_GROUPBEZ_TEXT /MSG/RGROUPBEZ
/MSG/BWR_GRPAGRDBEZ_TEXT /MSG/RGRPAGRDBEZ
/MSG/BWR_GRPSTATBEZ_TEXT /MSG/RGRPSTATBEZ
/MSG/BWR_GRPTYPBEZ_TEXT /MSG/RGRPTYPBEZ
/MSG/BWR_GSNAMBEZ_TEXT /MSG/RGSNAMBEZ
/MSG/BWR_GUVMODBEZ_TEXT /MSG/RGUVMODBEZ
/MSG/BWR_GUVTYPBEZ_TEXT /MSG/RGUVTYPBEZ
/MSG/BWR_GUVZEILBEZ_TEXT /MSG/RGUVZEILBEZ
/MSG/BWR_INDEXKZBEZ_TEXT /MSG/RINDEXKZBEZ
/MSG/BWR_IXDEFBEZ_TEXT /MSG/RIXDEFBEZ
/MSG/BWR_KKBUKZBEZ_TEXT /MSG/RKKBUKZBEZ
/MSG/BWR_KKSYS_TEXT_TEXT /MSG/RKKSYS_TEXT
/MSG/BWR_KLAUSBEZ_TEXT /MSG/RKLAUSBEZ
/MSG/BWR_KONDKZBEZ_TEXT /MSG/RKONDKZBEZ
/MSG/BWR_KUENDARBEZ_TEXT /MSG/RKUENDARBEZ
/MSG/BWR_LAEBEZ_TEXT /MSG/RLAEBEZ
/MSG/BWR_LDU_TYPBEZ_TEXT /MSG/RLDU_TYPBEZ
/MSG/BWR_LOBBAUMBEZ_TEXT /MSG/RLOBBAUMBEZ
/MSG/BWR_LOBHIERBEZ_TEXT /MSG/RLOBHIERBEZ
/MSG/BWR_NODEBEZ_TEXT /MSG/RNODEBEZ
/MSG/BWR_PTFABGRBEZ_TEXT /MSG/RPTFABGRBEZ
/MSG/BWR_PTFKZBEZ_TEXT /MSG/RPTFKZBEZ
/MSG/BWR_PTFRAZBEZ_TEXT /MSG/RPTFRAZBEZ
/MSG/BWR_PTFRUMFBEZ_TEXT /MSG/RPTFRUMFBEZ
/MSG/BWR_PTFTYPBEZ_TEXT /MSG/RPTFTYPBEZ
/MSG/BWR_RANGTYPBEZ_TEXT /MSG/RRANGTYPBEZ

/MSG/BWR_RBASISTBEZ_TEXT /MSG/RRBASISTBEZ
/MSG/BWR_REBENEBEZ_TEXT /MSG/RREBENEBEZ
/MSG/BWR_RECAPTUBEZ_TEXT /MSG/RRECAPTUBEZ
/MSG/BWR_RESKZBEZ_TEXT /MSG/RRESKZBEZ
/MSG/BWR_RESOTYPBEZ_TEXT /MSG/RRESOTYPBEZ
/MSG/BWR_RESULTBEZ_TEXT /MSG/RRESULTBEZ
/MSG/BWR_RIMETHBEZ_TEXT /MSG/RRIMETHBEZ
/MSG/BWR_ROLTYPBEZ_TEXT /MSG/RROLTYPBEZ
/MSG/BWR_ROL_RVBEZ_TEXT /MSG/RROL_RVBEZ
/MSG/BWR_ROWBEZ_TEXT /MSG/RROWBEZ
/MSG/BWR_RVOKLASBEZ_TEXT /MSG/RRVOKLASBEZ
/MSG/BWR_RVOKMODBEZ_TEXT /MSG/RRVOKMODBEZ
/MSG/BWR_RVOSTATBEZ_TEXT /MSG/RRVOSTATBEZ
/MSG/BWR_RVO_HHBEZ_TEXT /MSG/RRVO_HHBEZ
/MSG/BWR_RVSCHKZBEZ_TEXT /MSG/RRVSCHKZBEZ
/MSG/BWR_RVSKZ_KBEZ_TEXT /MSG/RRVSKZ_KBEZ
/MSG/BWR_SCHADKLBEZ_TEXT /MSG/RSCHADKLBEZ
/MSG/BWR_SCTYPBEZ_TEXT /MSG/RSCTYPBEZ
/MSG/BWR_SCURSBEZ_TEXT /MSG/RSCURSBEZ
/MSG/BWR_SEBENEBEZ_TEXT /MSG/RSEBENEBEZ
/MSG/BWR_SETCLASBEZ_TEXT /MSG/RSETCLASBEZ
/MSG/BWR_SETHEADERT_TEXT /MSG/RSETHEADERT
/MSG/BWR_SETLINET_TEXT /MSG/RSETLINET
/MSG/BWR_SOLVKBEZ_TEXT /MSG/RSOLVKBEZ
/MSG/BWR_SPALTBLBEZ_TEXT /MSG/RSPALTBLBEZ
/MSG/BWR_SPERRGRBEZ_TEXT /MSG/RSPERRGRBEZ

/MSG/BWR_STATTABBEZ_TEXT /MSG/RSTATTABBEZ
/MSG/BWR_STATUSBEZ_TEXT /MSG/RSTATUSBEZ
/MSG/BWR_STATYPBEZ_TEXT /MSG/RSTATYPBEZ
/MSG/BWR_STBRCHBEZ_TEXT /MSG/RSTBRCHBEZ
/MSG/BWR_STELLEBEZ_TEXT /MSG/RSTELLEBEZ
/MSG/BWR_STFFANWBEZ_TEXT /MSG/RSTFFANWBEZ
/MSG/BWR_STPRMODBEZ_TEXT /MSG/RSTPRMODBEZ
/MSG/BWR_SUMKZBEZ_TEXT /MSG/RSUMKZBEZ
/MSG/BWR_TOLGRPBEZ_TEXT /MSG/RTOLGRPBEZ
/MSG/BWR_USEATTRBEZ_TEXT /MSG/RUSEATTRBEZ
/MSG/BWR_UTILIZBEZ_TEXT /MSG/RUTILIZBEZ
/MSG/BWR_VERBARTBEZ_TEXT /MSG/RVERBARTBEZ
/MSG/BWR_VERSINTBEZ_TEXT /MSG/RVERSINTBEZ
/MSG/BWR_VERWENDBEZ_TEXT /MSG/RVERWENDBEZ
/MSG/BWR_VJGJ_KZBEZ_TEXT /MSG/RVJGJ_KZBEZ
/MSG/BWR_VJKZBEZ_TEXT /MSG/RVJKZBEZ
/MSG/BWR_VORTRAGBEZ_TEXT /MSG/RVORTRAGBEZ
/MSG/BWR_VTGAGRBEZ_TEXT /MSG/RVTGAGRBEZ
/MSG/BWR_VTGARTBEZ_TEXT /MSG/RVTGARTBEZ
/MSG/BWR_VTGRBBEZ_TEXT /MSG/RVTGRBBEZ
/MSG/BWR_VTGTYPBEZ_TEXT /MSG/RVTGTYPBEZ
/MSG/BWR_VUABHKBEZ_TEXT /MSG/RVUABHKBEZ
/MSG/BWR_WABRCHBEZ_TEXT /MSG/RWABRCHBEZ
/MSG/BWR_WAMETHBEZ_TEXT /MSG/RWAMETHBEZ
/MSG/BWR_WARTGRPBEZ_TEXT /MSG/RWARTGRPBEZ
/MSG/BWR_WHGBEHBEZ_TEXT /MSG/RWHGBEHBEZ

/MSG/BWR_ZEITANGBEZ_TEXT /MSG/RZEITANGBEZ
/MSG/BWR_ZLVERKZBEZ_TEXT /MSG/RZLVERKZBEZ
/MSG/BWR__GPSTATBEZ_TEXT /MSG/R_GPSTATBEZ
12.8.4 Extractors for Basic System Transaction Data
The extractors listed below enable the extraction of data fields from application tables in Basic System that
contain transaction data.
/MSG/BWR_ABR /MSG/RABR
/MSG/BWR_ABRIDXZUO /MSG/RABRIDXZUO
/MSG/BWR_ABRZUO /MSG/RABRZUO
/MSG/BWR_ABR_DRUCK /MSG/RABR_DRUCK
/MSG/BWR_ABR_ER_AL /MSG/RABR_ER_AL
/MSG/BWR_ACCOUNTING_ABRBU /MSG/BWRIA_DOC
/MSG/BWR_ANTAEND /MSG/RANTAEND
/MSG/BWR_ANTPART /MSG/RANTPART
/MSG/BWR_BESTANT /MSG/RBESTANT
/MSG/BWR_BILFREI /MSG/RBILFREI
/MSG/BWR_BORDERO /MSG/RBORDERO
/MSG/BWR_BORD_ITEM /MSG/RBORD_ITEM
/MSG/BWR_BORD_ZUO /MSG/RBORD_ZUO
/MSG/BWR_BRCHSPLIT /MSG/RBRCHSPLIT
/MSG/BWR_EARCURPROT /MSG/REARCURPROT
/MSG/BWR_F_KK_BU /MSG/RF_KK_BU
/MSG/BWR_F_KK_SALDO /MSG/RF_KK_SALDO

/MSG/BWR_RESULTS /MSG/RRESULTS
/MSG/BWR_RESULTS_CO /MSG/RRESULTS_CO
/MSG/BWR_RETROABR /MSG/RRETROABR
/MSG/BWR_SCHADEN /MSG/RSCHADEN
/MSG/BWR_SDNLOGTEXT /MSG/RSDNLOGTEXT
/MSG/BWR_WKANTSCHAD /MSG/RWKANTSCHAD
/MSG/BWR_WKDEPOT /MSG/RWKDEPOT
/MSG/BWR_WKDEPOT_BU /MSG/RWKDEPOT_BU
/MSG/BWR_WKGUVABR /MSG/RWKGUVABR
/MSG/BWR_WKGUVORG /MSG/RWKGUVORG
/MSG/BWR_WKLISTEC /MSG/RWKLISTEC
12.8.5 Extractors for Risk Manager Master Data
The extractors listed below enable the extraction of data fields from application tables in Risk Manager (Non-
Life) that contain master data.
/MSG/BWH_BATCHLOG_MD /MSG/HBATCHLOG
/MSG/BWH_BATCTRL_GB_MD /MSG/HBATCTRL_GB
/MSG/BWH_BAT_CTRL_MD /MSG/HBAT_CTRL
/MSG/BWH_BC_ABR_MD /MSG/HBC_ABR
/MSG/BWH_BC_COPYTAB_MD /MSG/HBC_COPYTAB
/MSG/BWH_BC_DEVCLAS_MD /MSG/HBC_DEVCLAS
/MSG/BWH_BC_MAXBAT_MD /MSG/HBC_MAXBAT
/MSG/BWH_BC_POLVL_MD /MSG/HBC_POLVL
/MSG/BWH_BC_RMMAIN_MD /MSG/HBC_RMMAIN

/MSG/BWH_BC_RM_MDT_MD /MSG/HBC_RM_MDT
/MSG/BWH_BC_VTGGET_MD /MSG/HBC_VTGGET
/MSG/BWH_BC_VTGPER_MD /MSG/HBC_VTGPER
/MSG/BWH_BC_VTGTEMP_MD /MSG/HBC_VTGTEMP
/MSG/BWH_BC_WERTART_MD /MSG/HBC_WERTART
/MSG/BWH_BETPARTNER_MD /MSG/HBETPARTNER
/MSG/BWH_BEZTYP_MD /MSG/HBEZTYP
/MSG/BWH_BUK_CHAIN_MD /MSG/HBUK_CHAIN
/MSG/BWH_BUK_CHN_MD /MSG/HBUK_CHN
/MSG/BWH_BUK_CHNLVL_MD /MSG/HBUK_CHNLVL
/MSG/BWH_BUK_PTF_AL_MD /MSG/HBUK_PTF_AL
/MSG/BWH_CESSDEF_MD /MSG/HCESSDEF
/MSG/BWH_CHECKFCT_MD /MSG/HCHECKFCT
/MSG/BWH_CHECKMODUL_MD /MSG/HCHECKMODUL
/MSG/BWH_CLAIMPR_MD /MSG/HCLAIMPR
/MSG/BWH_CLINC_MD /MSG/HCLINC
/MSG/BWH_CMCHECK_MD /MSG/HCMCHECK
/MSG/BWH_CONFSTAT_MD /MSG/HCONFSTAT
/MSG/BWH_COVTYP_MD /MSG/HCOVTYP
/MSG/BWH_COVTYPCTRL_MD /MSG/HCOVTYPCTRL
/MSG/BWH_COVTYPD_MD /MSG/HCOVTYPD
/MSG/BWH_CUST_BUKRS_MD /MSG/HCUST_BUKRS
/MSG/BWH_DIATYP_MD /MSG/HDIATYP
/MSG/BWH_DOCCUST_MD /MSG/HDOCCUST
/MSG/BWH_DOCCUST_2_MD /MSG/HDOCCUST_2
/MSG/BWH_ERTYP_MD /MSG/HERTYP

/MSG/BWH_ESDEF_MD /MSG/HESDEF
/MSG/BWH_ESDEFTAB_MD /MSG/HESDEFTAB
/MSG/BWH_ESERVT_MD /MSG/HESERVT
/MSG/BWH_FACTOR_MD /MSG/HFACTOR
/MSG/BWH_FIXBETPART_MD /MSG/HFIXBETPART
/MSG/BWH_FLDGRPBUK_MD /MSG/HFLDGRPBUK
/MSG/BWH_FLDGRPMODR_MD /MSG/HFLDGRPMODR
/MSG/BWH_FLDGRPSTA2_MD /MSG/HFLDGRPSTA2
/MSG/BWH_FLDGRPSTAT_MD /MSG/HFLDGRPSTAT
/MSG/BWH_GRPTYP_MD /MSG/HGRPTYP
/MSG/BWH_GRPTYPFIX_MD /MSG/HGRPTYPFIX
/MSG/BWH_LIABCD_MD /MSG/HLIABCD
/MSG/BWH_LS_COB_MD /MSG/HLS_COB
/MSG/BWH_LUD_DEF_MD /MSG/HLUD_DEF
/MSG/BWH_MAXIMRELFI_MD /MSG/HMAXIMRELFI
/MSG/BWH_METHOD_MD /MSG/HMETHOD
/MSG/BWH_MODRCOND_MD /MSG/HMODRCOND
/MSG/BWH_MODREAS_MD /MSG/HMODREAS
/MSG/BWH_MODREASBEZ_MD /MSG/HMODREASBEZ
/MSG/BWH_MOP_MD /MSG/HMOP
/MSG/BWH_OBJTYP_MD /MSG/HOBJTYP
/MSG/BWH_OBJ_AL_SEL_MD /MSG/HOBJ_AL_SEL
/MSG/BWH_OBJ_NAMELO_MD /MSG/HOBJ_NAMELO
/MSG/BWH_OPMODE_MD /MSG/HOPMODE
/MSG/BWH_OPMODEHIER_MD /MSG/HOPMODEHIER
/MSG/BWH_ORIGIN_MD /MSG/HORIGIN

/MSG/BWH_POLPOST_AL_MD /MSG/HPOLPOST_AL
/MSG/BWH_POLTYP_MD /MSG/HPOLTYP
/MSG/BWH_POLTYPCTRL_MD /MSG/HPOLTYPCTRL
/MSG/BWH_POLTYPD_MD /MSG/HPOLTYPD
/MSG/BWH_POLTYP_INT_MD /MSG/HPOLTYP_INT
/MSG/BWH_POSCOVT_AL_MD /MSG/HPOSCOVT_AL
/MSG/BWH_POSTYP_MD /MSG/HPOSTYP
/MSG/BWH_POSTYPCTRL_MD /MSG/HPOSTYPCTRL
/MSG/BWH_POSTYPD_MD /MSG/HPOSTYPD
/MSG/BWH_PREMACC_MD /MSG/HPREMACC
/MSG/BWH_PREMINC_MD /MSG/HPREMINC
/MSG/BWH_PREMTYP_MD /MSG/HPREMTYP
/MSG/BWH_PROC_ABBR_MD /MSG/HPROC_ABBR
/MSG/BWH_PRTTYP_MD /MSG/HPRTTYP
/MSG/BWH_REFTYPE_MD /MSG/HREFTYPE
/MSG/BWH_RIC_DEF_MD /MSG/HRIC_DEF
/MSG/BWH_RIMETH_MD /MSG/HRIMETH
/MSG/BWH_RMSECTS_MD /MSG/HRMSECTS
/MSG/BWH_SCG_MD /MSG/HSCG
/MSG/BWH_SETSEARCH_MD /MSG/HSETSEARCH
/MSG/BWH_SP_TYP_MD /MSG/HSP_TYP
/MSG/BWH_STATUS_MD /MSG/HSTATUS
/MSG/BWH_STATUS_FNC_MD /MSG/HSTATUS_FNC
/MSG/BWH_ST_CHAIN_MD /MSG/HST_CHAIN
/MSG/BWH_ST_MODR_MD /MSG/HST_MODR
/MSG/BWH_TIMEEXP_MD /MSG/HTIMEEXP

/MSG/BWH_TOA_MD /MSG/HTOA
/MSG/BWH_U_ADR_MD /MSG/HU_ADR
/MSG/BWH_U_AIRCR_MD /MSG/HU_AIRCR
/MSG/BWH_U_BURCO_MD /MSG/HU_BURCO
/MSG/BWH_U_CATIN_MD /MSG/HU_CATIN
/MSG/BWH_U_CLASA_MD /MSG/HU_CLASA
/MSG/BWH_U_CLASB_MD /MSG/HU_CLASB
/MSG/BWH_U_CLAUS_MD /MSG/HU_CLAUS
/MSG/BWH_U_COB_MD /MSG/HU_COB
/MSG/BWH_U_COVER_MD /MSG/HU_COVER
/MSG/BWH_U_CREST_MD /MSG/HU_CREST
/MSG/BWH_U_EXPOB_MD /MSG/HU_EXPOB
/MSG/BWH_U_EXPOD_MD /MSG/HU_EXPOD
/MSG/BWH_U_EXPOT_MD /MSG/HU_EXPOT
/MSG/BWH_U_HAZAR_MD /MSG/HU_HAZAR
/MSG/BWH_U_HBRBUKKL_MD /MSG/HU_HBRBUKKL
/MSG/BWH_U_HBRBUKRS_MD /MSG/HU_HBRBUKRS
/MSG/BWH_U_HBRBUSET_MD /MSG/HU_HBRBUSET
/MSG/BWH_U_INDXT_MD /MSG/HU_INDXT
/MSG/BWH_U_KBOND_MD /MSG/HU_KBOND
/MSG/BWH_U_LAUNC_MD /MSG/HU_LAUNC
/MSG/BWH_U_LAUNT_MD /MSG/HU_LAUNT
/MSG/BWH_U_MAPRULES_MD /MSG/HU_MAPRULES
/MSG/BWH_U_MCOB_MD /MSG/HU_MCOB
/MSG/BWH_U_MCONV_MD /MSG/HU_MCONV
/MSG/BWH_U_OCCUP_MD /MSG/HU_OCCUP

/MSG/BWH_U_OFFIC_MD /MSG/HU_OFFIC
/MSG/BWH_U_OPTYP_MD /MSG/HU_OPTYP
/MSG/BWH_U_PERCP_MD /MSG/HU_PERCP
/MSG/BWH_U_PERIL_MD /MSG/HU_PERIL
/MSG/BWH_U_PHASE_MD /MSG/HU_PHASE
/MSG/BWH_U_PHCOV_MD /MSG/HU_PHCOV
/MSG/BWH_U_PREBT_MD /MSG/HU_PREBT
/MSG/BWH_U_PREMB_MD /MSG/HU_PREMB
/MSG/BWH_U_QUACL_MD /MSG/HU_QUACL
/MSG/BWH_U_QUOTM_MD /MSG/HU_QUOTM
/MSG/BWH_U_RATES_MD /MSG/HU_RATES
/MSG/BWH_U_RATET_MD /MSG/HU_RATET
/MSG/BWH_U_RATGA_MD /MSG/HU_RATGA
/MSG/BWH_U_RBRANZUO_MD /MSG/HU_RBRANZUO
/MSG/BWH_U_REVTY_MD /MSG/HU_REVTY
/MSG/BWH_U_ROLE_MD /MSG/HU_ROLE
/MSG/BWH_U_SATMA_MD /MSG/HU_SATMA
/MSG/BWH_U_SATTY_MD /MSG/HU_SATTY
/MSG/BWH_U_SESCR_MD /MSG/HU_SESCR
/MSG/BWH_U_SHIPT_MD /MSG/HU_SHIPT
/MSG/BWH_U_SIZGR_MD /MSG/HU_SIZGR
/MSG/BWH_U_SRISK_MD /MSG/HU_SRISK
/MSG/BWH_U_SUBJT_MD /MSG/HU_SUBJT
/MSG/BWH_U_TRIGG_MD /MSG/HU_TRIGG
/MSG/BWH_U_TYSUM_MD /MSG/HU_TYSUM
/MSG/BWH_U_WABUCZUO_MD /MSG/HU_WABUCZUO

/MSG/BWH_VGLOP_MD /MSG/HVGLOP
/MSG/BWH_WACAL_CPLX_MD /MSG/HWACAL_CPLX
/MSG/BWH_WACAL_SIMP_MD /MSG/HWACAL_SIMP
/MSG/BWH_WAPOS_MD /MSG/HWAPOS
/MSG/BWH_WASTELLE_MD /MSG/HWASTELLE
/MSG/BWH_WATYPEN_MD /MSG/HWATYPEN
/MSG/BWH_WA_COMBI_MD /MSG/HWA_COMBI
/MSG/BWH_WERTART_MD /MSG/HWERTART
/MSG/BWH_ZBK_DBK_AL_MD /MSG/HZBK_DBK_AL
12.8.6 Extractors for Risk Manager Texts
Life) that contain texts.
/MSG/BWH_ACTIVBEZ_TEXT /MSG/HACTIVBEZ
/MSG/BWH_BENTYPBEZ_TEXT /MSG/HBENTYPBEZ
/MSG/BWH_BUK_CHNBEZ_TEXT /MSG/HBUK_CHNBEZ
/MSG/BWH_CLAIMPRBEZ_TEXT /MSG/HCLAIMPRBEZ
/MSG/BWH_CLINCBEZ_TEXT /MSG/HCLINCBEZ
/MSG/BWH_COVTYPBEZ_TEXT /MSG/HCOVTYPBEZ
/MSG/BWH_DIATYPBEZ_TEXT /MSG/HDIATYPBEZ
/MSG/BWH_DOCCUSTBEZ_TEXT /MSG/HDOCCUSTBEZ
/MSG/BWH_ERTYPBEZ_TEXT /MSG/HERTYPBEZ
/MSG/BWH_ESERVTBEZ_TEXT /MSG/HESERVTBEZ
/MSG/BWH_FACTORBEZ_TEXT /MSG/HFACTORBEZ

/MSG/BWH_FELDGRPBEZ_TEXT /MSG/HFELDGRPBEZ
/MSG/BWH_GRPTYPBEZ_TEXT /MSG/HGRPTYPBEZ
/MSG/BWH_LIABCDBEZ_TEXT /MSG/HLIABCDBEZ
/MSG/BWH_METHODBEZ_TEXT /MSG/HMETHODBEZ
/MSG/BWH_MOPBEZ_TEXT /MSG/HMOPBEZ
/MSG/BWH_OBJTYPBEZ_TEXT /MSG/HOBJTYPBEZ
/MSG/BWH_OPMODEBEZ_TEXT /MSG/HOPMODEBEZ
/MSG/BWH_ORIGINBEZ_TEXT /MSG/HORIGINBEZ
/MSG/BWH_POLAKZ_TEXT /MSG/HPOLAKZ
/MSG/BWH_POLTYPBEZ_TEXT /MSG/HPOLTYPBEZ
/MSG/BWH_POSTYPBEZ_TEXT /MSG/HPOSTYPBEZ
/MSG/BWH_PREMACCBEZ_TEXT /MSG/HPREMACCBEZ
/MSG/BWH_PREMINCBEZ_TEXT /MSG/HPREMINCBEZ
/MSG/BWH_PREMTYPBEZ_TEXT /MSG/HPREMTYPBEZ
/MSG/BWH_PROC_ABBEZ_TEXT /MSG/HPROC_ABBEZ
/MSG/BWH_PRTTYPBEZ_TEXT /MSG/HPRTTYPBEZ
/MSG/BWH_REFTYPEBEZ_TEXT /MSG/HREFTYPEBEZ
/MSG/BWH_RELTYPBEZ_TEXT /MSG/HRELTYPBEZ
/MSG/BWH_RIMETHBEZ_TEXT /MSG/HRIMETHBEZ
/MSG/BWH_RMSECTSBEZ_TEXT /MSG/HRMSECTSBEZ
/MSG/BWH_SP_TYPBEZ_TEXT /MSG/HSP_TYPBEZ
/MSG/BWH_STATUSBEZ_TEXT /MSG/HSTATUSBEZ
/MSG/BWH_TIMEEXPBEZ_TEXT /MSG/HTIMEEXPBEZ
/MSG/BWH_TOABEZ_TEXT /MSG/HTOABEZ
/MSG/BWH_U_ADRBEZ_TEXT /MSG/HU_ADRBEZ
/MSG/BWH_U_AIRCRBEZ_TEXT /MSG/HU_AIRCRBEZ

/MSG/BWH_U_BURCOBEZ_TEXT /MSG/HU_BURCOBEZ
/MSG/BWH_U_CATINBEZ_TEXT /MSG/HU_CATINBEZ
/MSG/BWH_U_CLASABEZ_TEXT /MSG/HU_CLASABEZ
/MSG/BWH_U_CLASBBEZ_TEXT /MSG/HU_CLASBBEZ
/MSG/BWH_U_CLAUSBEZ_TEXT /MSG/HU_CLAUSBEZ
/MSG/BWH_U_COBBEZ_TEXT /MSG/HU_COBBEZ
/MSG/BWH_U_COVERBEZ_TEXT /MSG/HU_COVERBEZ
/MSG/BWH_U_CRESTBEZ_TEXT /MSG/HU_CRESTBEZ
/MSG/BWH_U_EXPOBBEZ_TEXT /MSG/HU_EXPOBBEZ
/MSG/BWH_U_EXPODBEZ_TEXT /MSG/HU_EXPODBEZ
/MSG/BWH_U_EXPOTBEZ_TEXT /MSG/HU_EXPOTBEZ
/MSG/BWH_U_HAZARBEZ_TEXT /MSG/HU_HAZARBEZ
/MSG/BWH_U_INDXTBEZ_TEXT /MSG/HU_INDXTBEZ
/MSG/BWH_U_KBONDBEZ_TEXT /MSG/HU_KBONDBEZ
/MSG/BWH_U_LAUNCBEZ_TEXT /MSG/HU_LAUNCBEZ
/MSG/BWH_U_LAUNTBEZ_TEXT /MSG/HU_LAUNTBEZ
/MSG/BWH_U_MCOBBEZ_TEXT /MSG/HU_MCOBBEZ
/MSG/BWH_U_MCONVBEZ_TEXT /MSG/HU_MCONVBEZ
/MSG/BWH_U_OFFICBEZ_TEXT /MSG/HU_OFFICBEZ
/MSG/BWH_U_OPTYPBEZ_TEXT /MSG/HU_OPTYPBEZ
/MSG/BWH_U_PERCPBEZ_TEXT /MSG/HU_PERCPBEZ
/MSG/BWH_U_PERILBEZ_TEXT /MSG/HU_PERILBEZ
/MSG/BWH_U_PHASEBEZ_TEXT /MSG/HU_PHASEBEZ
/MSG/BWH_U_PHCOVBEZ_TEXT /MSG/HU_PHCOVBEZ
/MSG/BWH_U_PREBTBEZ_TEXT /MSG/HU_PREBTBEZ
/MSG/BWH_U_PREMBBEZ_TEXT /MSG/HU_PREMBBEZ

/MSG/BWH_U_QUACLBEZ_TEXT /MSG/HU_QUACLBEZ
/MSG/BWH_U_QUOTMBEZ_TEXT /MSG/HU_QUOTMBEZ
/MSG/BWH_U_RATESBEZ_TEXT /MSG/HU_RATESBEZ
/MSG/BWH_U_RATETBEZ_TEXT /MSG/HU_RATETBEZ
/MSG/BWH_U_RATGABEZ_TEXT /MSG/HU_RATGABEZ
/MSG/BWH_U_REVTYBEZ_TEXT /MSG/HU_REVTYBEZ
/MSG/BWH_U_SATMABEZ_TEXT /MSG/HU_SATMABEZ
/MSG/BWH_U_SATTYBEZ_TEXT /MSG/HU_SATTYBEZ
/MSG/BWH_U_SESCRBEZ_TEXT /MSG/HU_SESCRBEZ
/MSG/BWH_U_SHIPTBEZ_TEXT /MSG/HU_SHIPTBEZ
/MSG/BWH_U_SIZGRBEZ_TEXT /MSG/HU_SIZGRBEZ
/MSG/BWH_U_SRISKBEZ_TEXT /MSG/HU_SRISKBEZ
/MSG/BWH_U_SUBJTBEZ_TEXT /MSG/HU_SUBJTBEZ
/MSG/BWH_U_TRIGGBEZ_TEXT /MSG/HU_TRIGGBEZ
/MSG/BWH_U_TYSUMBEZ_TEXT /MSG/HU_TYSUMBEZ
/MSG/BWH_WERTARTBEZ_TEXT /MSG/HWERTARTBEZ
12.8.7 Extractors for Risk Manager Transaction Data
Life) that contain transaction data.
/MSG/BWH_BENEFIT /MSG/HBENEFIT
/MSG/BWH_BENPREM_AL /MSG/HBENPREM_AL
/MSG/BWH_BENST_VLTP /MSG/HBENST_VLTP
/MSG/BWH_BENTYP /MSG/HBENTYP

/MSG/BWH_BEN_ER_AL /MSG/HBEN_ER_AL
/MSG/BWH_BEN_HD /MSG/HBEN_HD
/MSG/BWH_BEN_LUD /MSG/HBEN_LUD
/MSG/BWH_BEN_OBJ_AL /MSG/HBEN_OBJ_AL
/MSG/BWH_BEN_VL /MSG/HBEN_VL
/MSG/BWH_CESSION /MSG/HCESSION
/MSG/BWH_CLAIMGRP /MSG/HCLAIMGRP
/MSG/BWH_CLAIMPOAL /MSG/HCLAIMPOAL
/MSG/BWH_COVERAGE /MSG/HCOVERAGE
/MSG/BWH_COVER_VL /MSG/HCOVER_VL
/MSG/BWH_COVST_VLTP /MSG/HCOVST_VLTP
/MSG/BWH_COV_ER_AL /MSG/HCOV_ER_AL
/MSG/BWH_COV_OBJ_AL /MSG/HCOV_OBJ_AL
/MSG/BWH_ENDORSEMNT /MSG/HENDORSEMNT
/MSG/BWH_ERROR_MIG /MSG/HERROR_MIG
/MSG/BWH_EXCLUSION /MSG/HEXCLUSION
/MSG/BWH_EXTREF /MSG/HEXTREF
/MSG/BWH_GP_IN_HD /MSG/HGP_IN_HD
/MSG/BWH_GRP /MSG/HGRP
/MSG/BWH_GRPST_VLTP /MSG/HGRPST_VLTP
/MSG/BWH_GRP_ER_AL /MSG/HGRP_ER_AL
/MSG/BWH_GRP_HD /MSG/HGRP_HD
/MSG/BWH_GRP_POS_AL /MSG/HGRP_POS_AL
/MSG/BWH_GRP_PRT_AL /MSG/HGRP_PRT_AL
/MSG/BWH_GRP_SYN /MSG/HGRP_SYN
/MSG/BWH_GRP_S_DATE /MSG/HGRP_S_DATE

/MSG/BWH_GRP_VL /MSG/HGRP_VL
/MSG/BWH_GUIDREF /MSG/HGUIDREF
/MSG/BWH_INVSEARCH /MSG/HINVSEARCH
/MSG/BWH_LUD /MSG/HLUD
/MSG/BWH_MAXIMIZE /MSG/HMAXIMIZE
/MSG/BWH_OBJ01 /MSG/HOBJ01
/MSG/BWH_OBJ11 /MSG/HOBJ11
/MSG/BWH_OBJECT /MSG/HOBJECT
/MSG/BWH_OBJ_AL /MSG/HOBJ_AL
/MSG/BWH_OBJ_ER_AL /MSG/HOBJ_ER_AL
/MSG/BWH_PARTNER_HD /MSG/HPARTNER_HD
/MSG/BWH_PERM_HD_FT /MSG/HPERM_HD_FT
/MSG/BWH_POLICY_HD /MSG/HPOLICY_HD
/MSG/BWH_POLST_VLTP /MSG/HPOLST_VLTP
/MSG/BWH_POL_ER_AL /MSG/HPOL_ER_AL
/MSG/BWH_POS /MSG/HPOS
/MSG/BWH_POSGRPMD /MSG/HPOSGRPMD
/MSG/BWH_POSST_VLTP /MSG/HPOSST_VLTP
/MSG/BWH_POS_ER_AL /MSG/HPOS_ER_AL
/MSG/BWH_POS_HD /MSG/HPOS_HD
/MSG/BWH_POS_S_DATE /MSG/HPOS_S_DATE
/MSG/BWH_POS_VL /MSG/HPOS_VL
/MSG/BWH_PREMIUM /MSG/HPREMIUM
/MSG/BWH_PREMOBJ_AL /MSG/HPREMOBJ_AL
/MSG/BWH_PREM_DST /MSG/HPREM_DST
/MSG/BWH_PREM_ER_AL /MSG/HPREM_ER_AL

/MSG/BWH_PREM_HD /MSG/HPREM_HD
/MSG/BWH_PREM_VL /MSG/HPREM_VL
/MSG/BWH_PRT /MSG/HPRT
/MSG/BWH_PRTPREMA /MSG/HPRTPREMA
/MSG/BWH_PRTPREM_HD /MSG/HPRTPREM_HD
/MSG/BWH_PRTST_VLTP /MSG/HPRTST_VLTP
/MSG/BWH_PRT_ER_AL /MSG/HPRT_ER_AL
/MSG/BWH_PRT_EXCL /MSG/HPRT_EXCL
/MSG/BWH_PRT_HD /MSG/HPRT_HD
/MSG/BWH_PRT_LUD /MSG/HPRT_LUD
/MSG/BWH_PRT_PART /MSG/HPRT_PART
/MSG/BWH_PRT_RDC /MSG/HPRT_RDC
/MSG/BWH_PRT_REINS /MSG/HPRT_REINS
/MSG/BWH_PRT_RIC /MSG/HPRT_RIC
/MSG/BWH_PRT_SCALE /MSG/HPRT_SCALE
/MSG/BWH_PRT_S_DATE /MSG/HPRT_S_DATE
/MSG/BWH_PRT_VL /MSG/HPRT_VL
/MSG/BWH_RELTYP /MSG/HRELTYP
/MSG/BWH_RESP_GRP /MSG/HRESP_GRP
/MSG/BWH_RESP_OBJ /MSG/HRESP_OBJ
/MSG/BWH_RESP_POL /MSG/HRESP_POL
/MSG/BWH_RESP_PRT /MSG/HRESP_PRT
/MSG/BWH_RIC /MSG/HRIC
/MSG/BWH_SEARCHINFO /MSG/HSEARCHINFO
/MSG/BWH_SNAP_MIG /MSG/HSNAP_MIG
/MSG/BWH_SNAP_SUB /MSG/HSNAP_SUB

/MSG/BWH_SNAP_TOP /MSG/HSNAP_TOP
/MSG/BWH_SPLITAREA /MSG/HSPLITAREA
/MSG/BWH_SPLITCURR /MSG/HSPLITCURR
/MSG/BWH_SPLITPERIL /MSG/HSPLITPERIL
/MSG/BWH_SPLIT_COB /MSG/HSPLIT_COB
/MSG/BWH_SPLIT_LOB /MSG/HSPLIT_LOB
/MSG/BWH_SPLIT_OOB /MSG/HSPLIT_OOB
/MSG/BWH_SS_POS_AL /MSG/HSS_POS_AL
/MSG/BWH_SS_PRT_AL /MSG/HSS_PRT_AL
/MSG/BWH_STATUSPROT /MSG/HSTATUSPROT
/MSG/BWH_TREE_BENEF /MSG/HTREE_BENEF
/MSG/BWH_TREE_COVER /MSG/HTREE_COVER
/MSG/BWH_TREE_OBJ /MSG/HTREE_OBJ
/MSG/BWH_TREE_POLHD /MSG/HTREE_POLHD
/MSG/BWH_TREE_POLIC /MSG/HTREE_POLIC
/MSG/BWH_TREE_POS /MSG/HTREE_POS
/MSG/BWH_TREE_PREMI /MSG/HTREE_PREMI
/MSG/BWH_UBEN_HD /MSG/HUBEN_HD
/MSG/BWH_UENDORSMNT /MSG/HUENDORSMNT
/MSG/BWH_UEXPINFO /MSG/HUEXPINFO
/MSG/BWH_UGRPDET /MSG/HUGRPDET
/MSG/BWH_UGRP_F_C /MSG/HUGRP_F_C
/MSG/BWH_UGRP_HD /MSG/HUGRP_HD
/MSG/BWH_UGRP_SUB /MSG/HUGRP_SUB
/MSG/BWH_UPERILS /MSG/HUPERILS
/MSG/BWH_UPHASES /MSG/HUPHASES

/MSG/BWH_UPOLICY_HD /MSG/HUPOLICY_HD
/MSG/BWH_UPOS /MSG/HUPOS
/MSG/BWH_UPOS_HD /MSG/HUPOS_HD
/MSG/BWH_UPOS_KBOND /MSG/HUPOS_KBOND
/MSG/BWH_UPREM_HD /MSG/HUPREM_HD
/MSG/BWH_UPRTDET /MSG/HUPRTDET
/MSG/BWH_UPRTDET_VL /MSG/HUPRTDET_VL
/MSG/BWH_UPRTOBJ_AL /MSG/HUPRTOBJ_AL
/MSG/BWH_U_HBEN_HD /MSG/HU_HBEN_HD
/MSG/BWH_U_HENDORSM /MSG/HU_HENDORSM
/MSG/BWH_U_HPOLICYH /MSG/HU_HPOLICYH
/MSG/BWH_U_HPOS /MSG/HU_HPOS
/MSG/BWH_U_HPOS_HD /MSG/HU_HPOS_HD
/MSG/BWH_U_HPOS_KBO /MSG/HU_HPOS_KBO
/MSG/BWH_U_HPREM_HD /MSG/HU_HPREM_HD
/MSG/BWH_WKLISTEC /MSG/HWKLISTEC
12.9 Generation of Histories in Basic System
Use
The history documents the changes made to the treaty, global conditions, loss, reinsurance program, treaty
calculation rules, and treaty groups.
Each time data is saved the system creates a delta history for the treaty, global conditions, loss, reinsurance
program, treaty calculation rules, and treaty groups.

Features
A delta history contains the changed data of the object between two save operations.
It documents the changes made to the treaty, global conditions, loss, reinsurance program, treaty calculation
rules, and treaty groups. If requested, it displays the changes made to the current object in a list.
The changes made to the older dataset are marked in different colors: The first row in the history list is always
displayed in the standard text color and reflects the status of the data when it was initially created. After this,
the system lists time stamps that document the changes made to the data. These changes are marked in a
different color from the standard text color.
The history also contains all the delta histories generated by the save operations.
The History pushbutton is available in the toolbar on the screens used to manage portfolios. When you choose
this pushbutton, the system provides you with an overview of the history statuses.
12.10 Archiving
Use
You use archiving to move data from the operational database to archive files. This helps you to ease the load
on your operational system.
Integration
The FS-RI system uses the standard SAP functions for archiving. For more information, see the documentation
for these functions.
Features
Archiving Objects
An archiving object contains all the business data for a business object (treaty, account, loss, and so on) that is
read from the database by a write program and deleted by the associated delete program after the data has
been successfully archived.
You can use transaction AOBJ to view the properties of individual archiving objects and, if necessary, to change
these objects (structure definition, related programs, Customizing, and so on).
For more information about the archiving objects delivered with the FS-RI system, see:
● Archiving Objects in Basic System [page 760]

● Archiving Objects in Risk Manager Non-Life [page 767]

Archived Tables
You can use transaction DB15 to view the dependent tables for the individual archiving objects. In return, you
can also find the archiving object that archives data from a specific table.
Archiving
You use transaction SARA to archive data. You can also call all the other transactions relevant for archiving data
from this transaction.
Archive Information System
You use transaction SARI to start the archive information system. You can use this transaction to display
information about archiving runs. You can also define and delete archive information structures and their
corresponding field catalogs (you cannot process activated information structures).
● Archive Explorer
Information about the written archives (an archive information structure must exist)
● Status
Status of the archiving runs started in the system
● Customizing
Creation and deletion of archive information structures and field catalogs (choose Environment Field
Catalogs )
Reloading Archived Data
 Caution
Data should be reloaded from an archive into the database only in urgent cases and by trained personnel.
The reloading of "old" data into an operational system can lead to inconsistencies.
Activities
1. Start the archiving process in one of the following ways:

○ Transaction: SARA
○ SAP menu: Tools Administration Administration Data Archiving
○ FS-RI menu: FS-RI: Reinsurance Periodic Processing Archive Administration
2. Write the data to the archive
Choose the pushbutton. The system creates an archive file. It then reads the data to be archived from
the database and saves this to an archive file in the file system. The criteria used by the system to find the
data to be archived depend on the actual archiving object (the selection methods are described for each
individual archiving object).
3. Delete the archived data from the operational database system
Choose the pushbutton. You can now access the archived data file only via the archive file, unless you
reload the data into the database.

 Caution
The system does not check the dependencies between different archiving objects. This is the
responsibility of the employee who is archiving the data.
Example:
The system does not check whether accounts still exist in the system for a treaty being archived. The
system cannot release such an account because the corresponding treaty no longer exists.
12.10.1 Archiving Objects in Basic System
Definition
An archiving object contains all the business data for a business object (treaty, account, loss, and so on) that is
read from the database by a write program and deleted by the associated delete program after the data has
Use
these objects (structure definition, related programs, Customizing, and so on).
Basic System contains the following archiving objects.
/MSG/RTTY: FS-RI Treaties
What is archived:
The system uses the archiving object /MSG/RTTY to archive all deleted Basic System treaties (all treaties to
which there are no references in Risk Manager tables) and delete these from the database.
The system does not check if there are dependencies between these treaties and any existing accounts. The
related accounts are not archived. The system uses the archiving object /MSG/RABR for this purpose.
Dependent database tables for “Treaty” business object:
/MSG/RANTAEND
/MSG/RH_LOBSPLIT
/MSG/RNPANG_HAFT
/MSG/RANTPART
/MSG/RH_NPANG_HA
/MSG/RNPANG_PR
/MSG/RAUDITVAL
/MSG/RH_NPANG_PR

/MSG/RPRODUCT
/MSG/RBESTANT
/MSG/RH_PRODUCT
/MSG/RPROGDIS
/MSG/RBRCHSPLIT
/MSG/RH_PROGDIS
/MSG/RPROGDISTR
/MSG/RCAPPROT
/MSG/RH_PROGDIST
/MSG/RPROPANG
/MSG/RCOND
/MSG/RH_PROPANG
/MSG/RPTFREG
/MSG/RCONDBASE
/MSG/RH_PTFREG
/MSG/RRETRO
/MSG/RDEPOREG
/MSG/RH_RETRO
/MSG/RRISTR1
/MSG/REARCLOC
/MSG/RH_RISTR1
/MSG/RRISTR2
/MSG/REARCLOCP
/MSG/RH_RISTR2
/MSG/RSECDIS
/MSG/REARCUR_HD
/MSG/RH_SETATTR
/MSG/RSETATTR
/MSG/REARCURBES2
/MSG/RH_SETS
/MSG/RSETS
/MSG/REARCURPROT
/MSG/RH_STAFFEL

/MSG/RSTAFFEL
/MSG/REXCLUSION
/MSG/RH_VABHKOND
/MSG/RVABHKOND
/MSG/REXPOSUR_VL/MSG/RH_VERTPLAN
/MSG/RVERTPLAN
/MSG/REXPOSURE
/MSG/RH_VTG
/MSG/RVTG
/MSG/REXTREF
/MSG/RH_VTG_ERAL
/MSG/RVTG_ER_AL
/MSG/RGARTSPLIT
/MSG/RH_VTGAERAL
/MSG/RVTGA_ER_AL
/MSG/RGEBSPLIT
/MSG/RH_VTGANT
/MSG/RVTGANT
/MSG/RGEFSPLIT
/MSG/RH_VTGANTKO
/MSG/RVTGANTKO
/MSG/RH_ANTPART
/MSG/RH_VTGAU
/MSG/RVTGAU
/MSG/RH_AUDITVAL
/MSG/RH_VTGBERAL
/MSG/RVTGAUATTR
/MSG/RH_BESTANT
/MSG/RH_VTGBEST
/MSG/RVTGAUDEF
/MSG/RH_BRCHSPLI
/MSG/RH_VTGBESTC
/MSG/RVTGB_ER_AL

/MSG/RH_CAPPROT
/MSG/RH_VTGBESTK
/MSG/RVTGBEST
/MSG/RH_COND
/MSG/RH_VTGBKLAU
/MSG/RVTGBESTCAP
/MSG/RH_CONDBASE
/MSG/RH_VTGPER
/MSG/RVTGBESTKO
/MSG/RH_DEPOREG
/MSG/RH_VTGTRG
/MSG/RVTGBKLAU
/MSG/RH_EARCLOC
/MSG/RH_VTGTRGCO
/MSG/RVTGPER
/MSG/RH_EARCLOCP
/MSG/RH_VUNABHKO
/MSG/RVTGTRG
/MSG/RH_EARCUR_H
/MSG/RH_VVERANTW
/MSG/RVTGTRGCOND
/MSG/RH_EARCURB2
/MSG/RH_VZPLAN
/MSG/RVUNABHKOND
/MSG/RH_EXCLUSIO
/MSG/RH_VZPLANTP
/MSG/RVVERANTW
/MSG/RH_EXPOS_VL
/MSG/RH_WAPLAN
/MSG/RVZPLAN
/MSG/RH_EXPOSURE
/MSG/RH_WHGSPLIT
/MSG/RVZPLAN_TOP

/MSG/RH_EXTREF
/MSG/RH_XLANTEIL
/MSG/RWAPLAN
/MSG/RH_GARTSPLI
/MSG/RH_XLFGR
/MSG/RWHGSPLIT
/MSG/RH_GEBSPLIT
/MSG/RH_ZUSATZDA
/MSG/RXLANTEIL
/MSG/RH_GEFSPLIT
/MSG/RKOMPREG
/MSG/RXLFGR
/MSG/RH_KOMPREG
/MSG/RLDU
/MSG/RZUSATZDAT
/MSG/RH_LDU
/MSG/RLOBSPLIT
/MSG/RABR: FS-RI Accounts
What is archived:
The system uses the archiving object /MSG/RABR to archive all non-life accounts (treaty class 3) with FI
posting dates before a retention period set by the user. The system uses the specified retention period and
the current date to calculate a retention date (always January 1 of the calculated year). It archives all accounts
with FI posting dates before this date. The accounts must also be assigned to a non-life treaty.
 Note
Since the accounts must be assigned to a treaty, they must be archived before the treaties otherwise
logical errors occur when you archive the accounts. The system does not archive accounts that are not
assigned to a treaty.
 Example
Account 1 Account 2 Account 3
FI posting date March 27, 1995 September 13, 1996 January 1, 1996
Current date: February 18, 2008
Retention period: 12 years (-> retention date = January 1, 1996)

Result: Only account 1 is archived. If the retention date is calculated exactly, account 3 should also fall
within the archiving period (February 18, 2008 – 12 years = February 18, 1996) but does not. This is
because when the system calculates the retention date, it considers only the year dates.
Note:
You can enter the retention period in years as a selection criterion.
Dependent database tables for “Account” business object:
/MSG/RABR
/MSG/RABRZUO2
/MSG/RH_EXTREF
/MSG/RABR_ER_AL
/MSG/RBU
/MSG/RH_RETROABR
/MSG/RABRIDXZUO
/MSG/REXTREF
/MSG/RRETROABR
/MSG/RABRZUO
/MSG/RH_ABRIDXZU
/MSG/R_U: FS-RI Losses
What is archived:
The system uses the archiving object /MSG/R_U to archive all deleted losses. It does not archive dependent
accounts.
Dependent database tables for the “Loss” business object:
/MSG/RSCHADEN
/MSG/RH_SCHADZEZ
/MSG/RSDNLOGTEXT
/MSG/RSCHADZUO
/MSG/RH_SCHADZUO
/MSG/RSCHADOBZUO
/MSG/RSCHADEGZUO
/MSG/RH_UVERANTW
/MSG/RH_SCHADOB
/MSG/RSCHADZEZUO
/MSG/RH_ZUSDN
/MSG/RSCHADPOZUO

/MSG/RUVERANTW
/MSG/RH_ZUSDNZEZ
/MSG/RH_SCHADPO
/MSG/RZUSDN
/MSG/RH_ZUSDNZUO
/MSG/HCLAIMGRP
/MSG/RZUSDNZEZUO
/MSG/RSDN_ER_AL
/MSG/HCLAIMPOAL
/MSG/RZUSDNZUO
/MSG/REXTREF
/MSG/RH_SCHADEGZ
/MSG/RH_SDN_ERAL
/MSG/RH_SCHADEN
/MSG/RH_EXTREF
/MSG/RBORD: FS-RI Bordereau
What is archived:
The system uses the archiving object /MSG/RBORD to archive all bordereaux that have no ungenerated items
(all accounts must be generated) and in which the FI posting dates for all accounts are before a specified
retention period.
Note:
You can enter the retention period in years as a selection criterion.
Dependent database tables for the “Bordereau” business object:
/MSG/RBORDERO
/MSG/RBORD_ITEM
/MSG/RBORD_ZUO
/MSG/RGRP: FS-RI Treaty Groups
What is archived:
The system uses the archiving object /MSG/RGRP to archive all deleted treaty groups.
Dependent database tables for the “Treaty Group” business object:
/MSG/RGRP_HD
/MSG/RGRPZU_BEST
/MSG/RH_GRPVERT
/MSG/RGRP

/MSG/RH_GRP_HD
/MSG/RH_GRPZBEST
/MSG/RGRPEARCUR
/MSG/RH_GRP
/MSG/RGRPVERT
/MSG/RH_GRPEARCU
/MSG/RRVO: FS-RI Reinsurance Program
What is archived:
The system uses the archiving object /MSG/RRVO to archive all deleted reinsurance programs.
Dependent database tables for the “Reinsurance Program” business object:
/MSG/RRVO
/MSG/RRVO_ABG
/MSG/RH_RVO_RANG
/MSG/RRVO_ZR
/MSG/RH_RVO
/MSG/RH_RVO_ZR
/MSG/RRVO_RANG
/MSG/RH_RVO_ABG
12.10.2 Archiving Objects in Risk Manager Non-Life
Definition
An archiving object contains all the business data for a business object (policy, account, group, and so on) that
is read from the database by a write program and deleted by the associated delete program after the data has
Use
these objects (structure definition, related programs, Customizing, and so on). FS-RI Risk Manager Non-Life
contains the following archiving objects. Archiving Objects According to FS-RI Objects
/MSG/HPOL: FS-RI Policies

What is archived:
The system uses the archiving object /MSG/HPOL to archive all Risk Manager policies with the status “To Be
Archived” (including history).
The system does not check if there are dependencies between these policies and any existing treaties or
accounts. It does not check if there are any technical dependencies between these policies and assigned
accumulation groups. The system archives the assignment tables for external references and objects but does
not archive the objects or references themselves.
Dependent database tables for the “Policy” business object:
/MSG/HBEN_ER_AL
/MSG/HH_POS_HD
/MSG/HPRT_ER_AL
/MSG/HBEN_HD
/MSG/HH_POS_S_DA
/MSG/HPRT_EXCL
/MSG/HBEN_LUD
/MSG/HH_POS_VL
/MSG/HPRT_HD
/MSG/HBEN_OBJ_AL
/MSG/HH_PREM_DST
/MSG/HPRT_LUD
/MSG/HBEN_VL
/MSG/HH_PREM_HD
/MSG/HPRT_PART
/MSG/HBENEFIT
/MSG/HH_PREMERAL
/MSG/HPRT_RDC
/MSG/HBENPREM_AL
/MSG/HH_PREMIUM
/MSG/HPRT_REINS
/MSG/HBENST_VLTP
/MSG/HH_PRT
/MSG/HPRT_RIC
/MSG/HCOVER_VL
/MSG/HH_PRT_ERAL

/MSG/HPRT_S_DATE
/MSG/HCOVERAGE
/MSG/HH_PRT_EXCL
/MSG/HPRT_SCALE
/MSG/HCOVST_VLTP
/MSG/HH_PRT_HD
/MSG/HPRT_VL
/MSG/HENDORSEMNT
/MSG/HH_PRT_LUD
/MSG/HPRTPREM
/MSG/HEXCLUSION
/MSG/HH_PRT_PART
/MSG/HPRTPREM_HD
/MSG/HGP_IN_HD
/MSG/HH_PRT_RDC
/MSG/HPRTPREMA
/MSG/HGRP
/MSG/HH_PRT_REIN
/MSG/HPRTST_VLTP
/MSG/HGRP_ER_AL
/MSG/HH_PRT_RIC
/MSG/HRESP_GRP
/MSG/HGRP_HD
/MSG/HH_PRT_S_DA
/MSG/HRESP_POL
/MSG/HGRP_POS_AL
/MSG/HH_PRT_SCAL
/MSG/HRESP_PRT
/MSG/HGRP_PRT_AL
/MSG/HH_PRT_VL
/MSG/HRIC
/MSG/HGRP_S_DATE
/MSG/HH_PRTPREM

/MSG/HSPLIT_COB
/MSG/HGRP_SYN
/MSG/HH_PRTPREMA
/MSG/HSPLIT_LOB
/MSG/HGRP_VL
/MSG/HH_PRTPREMH
/MSG/HSPLIT_OOB
/MSG/HGRPST_VLTP
/MSG/HH_RESP_GRP
/MSG/HSPLITAREA
/MSG/HH_BEN_ERAL
/MSG/HH_RESP_POL
/MSG/HSPLITCURR
/MSG/HH_BEN_HD
/MSG/HH_RESP_PRT
/MSG/HSPLITPERIL
/MSG/HH_BEN_LUD
/MSG/HH_RIC
/MSG/HU_HBEN_HD
/MSG/HH_BEN_OBJA
/MSG/HH_SPLITARE
/MSG/HU_HBNPRT_A
/MSG/HH_BEN_VL
/MSG/HH_SPLITCOB
/MSG/HU_HEXPINFO
/MSG/HH_BENEFIT
/MSG/HH_SPLITCUR
/MSG/HU_HGRP_F_C
/MSG/HH_BENPREMA
/MSG/HH_SPLITLOB
/MSG/HU_HGRP_HD
/MSG/HH_COV_ER_A
/MSG/HH_SPLITOOB

/MSG/HU_HGRP_SUB
/MSG/HH_COV_OBJA
/MSG/HH_SPLITPER
/MSG/HU_HGRPDET
/MSG/HH_COVER_VL
/MSG/HINVSEARCH
/MSG/HU_HPERILS
/MSG/HH_COVERAGE
/MSG/HLUD
/MSG/HU_HPHASES
/MSG/HH_ENDORSEM
/MSG/HPARTNER_HD
/MSG/HU_HPREM_HD
/MSG/HH_EXCLUSIO
/MSG/HPOL_ER_AL
/MSG/HU_HPRTDET
/MSG/HH_GP_IN_HD
/MSG/HPOLICY_HD
/MSG/HU_HPRTDETV
/MSG/HH_GRP
/MSG/HPOLST_VLTP
/MSG/HUBEN_HD
/MSG/HH_GRP_ERAL
/MSG/HPOS
/MSG/HUBNPRT_AL
/MSG/HH_GRP_HD
/MSG/HPOS_ER_AL
/MSG/HUEXPINFO
/MSG/HH_GRP_POSA
/MSG/HPOS_HD
/MSG/HUGRP_F_C
/MSG/HH_GRP_PRTA
/MSG/HPOS_S_DATE

/MSG/HUGRP_HD
/MSG/HH_GRP_S_DA
/MSG/HPOS_VL
/MSG/HUGRP_SUB
/MSG/HH_GRP_SYN
/MSG/HPOSST_VLTP
/MSG/HUGRPDET
/MSG/HH_GRP_VL
/MSG/HPREM_DST
/MSG/HUPOS
/MSG/HH_LUD
/MSG/HPREM_ER_AL
/MSG/HUPOS_HD
/MSG/HH_PARTNERH
/MSG/HPREM_HD
/MSG/HUPOS_KBOND
/MSG/HH_PG_IN_HD
/MSG/HPREM_VL
/MSG/HUPREM_HD
/MSG/HH_POL_ERAL
/MSG/HPREMIUM
/MSG/HUPRMPRT_AL
/MSG/HH_POLICYHD
/MSG/HPREMOBJ_AL
/MSG/HUPRTDET
/MSG/HOBJ: FS-RI Objects
What is archived:
The system uses the archiving object /MSG/HOBJ to archive all Risk Manager objects with the status “To Be
The system does not check if there are any dependencies between these objects and any assigned policies or
groups. It archives the assignment table for external references but does not archive the external references
themselves.
Dependent database tables for the “Object” business object:
/MSG/HBEN_OBJ_AL

/MSG/HH_PRT_HD
/MSG/HPRT_HD
/MSG/HCOV_OBJ_AL
/MSG/HH_RESP_OBJ
/MSG/HRESP_OBJ
/MSG/HGRP_HD
/MSG/HHOBJ01
/MSG/HUPRTOBJ_AL
/MSG/HH_BEN_OBJA
/MSG/HHOBJ11
/MSG/HWKLISTEC
/MSG/HH_COV_OBJA
/MSG/HOBJ_AL
/MSG/PCIPOST
/MSG/HH_GRP_HD
/MSG/HOBJ_ER_AL
/MSG/RBU
/MSG/HH_OBJ_AL
/MSG/HOBJ01
/MSG/REXPOSURE
/MSG/HH_OBJ_ER_A
/MSG/HOBJ11
/MSG/RH_EXPOSURE
/MSG/HH_OBJECT
/MSG/HOBJECT
/MSG/RH_SCHADOB
/MSG/HH_POLICYHD
/MSG/HPOLICY_HD
/MSG/RSCHADOBZUO
/MSG/HH_POS_HD
/MSG/HPOS_HD
/MSG/HH_PREMOBJA
/MSG/HPREMOBJ_AL

/MSG/HGRP: FS-RI Risk-Manager Non-Life 6.0 - Accumulation Groups
What is archived:
The system uses the archiving object /MSG/HGRP to archive all Risk Manager groups with the status “To Be
The system does not check if there are any dependencies between these objects and any assigned policies or
groups. The system does not archive the assignment table for external references.
Dependent database tables for “Accumulation Group” business object:
/MSG/HENDORSEMNT
/MSG/HH_PRT_LUD
/MSG/HPRT_S_DATE
/MSG/HGP_IN_HD
/MSG/HH_PRT_PART
/MSG/HPRT_SCALE
/MSG/HGRP
/MSG/HH_PRT_RDC
/MSG/HPRT_VL
/MSG/HGRP_ER_AL
/MSG/HH_PRT_REIN
/MSG/HPRTPREM_HD
/MSG/HGRP_POS_AL
/MSG/HH_PRT_RIC
/MSG/HPRTPREMA
/MSG/HGRP_PRT_AL
/MSG/HH_PRT_S_DA
/MSG/HPRTST_VLTP
/MSG/HGRP_S_DATE
/MSG/HH_PRT_SCAL
/MSG/HRESP_GRP
/MSG/HGRP_SYN
/MSG/HH_PRT_VL
/MSG/HRESP_PRT
/MSG/HGRP_VL
/MSG/HH_PRTPREMA
/MSG/HU_HBNPRT_A

/MSG/HGRPST_VLTP
/MSG/HH_PRTPREMH
/MSG/HU_HGRP_F_C
/MSG/HH_ENDORSEM
/MSG/HH_RESP_GRP
/MSG/HU_HGRP_HD
/MSG/HH_GP_IN_HD
/MSG/HH_RESP_PRT
/MSG/HU_HGRP_SUB
/MSG/HH_GRP
/MSG/HINVSEARCH
/MSG/HU_HGRPDET
/MSG/HH_GRP_ERAL
/MSG/HPI_SEC_ACC
/MSG/HU_HPRMPRTA
/MSG/HH_GRP_POSA
/MSG/HPI_SEC_GRP
/MSG/HU_HPRTDET
/MSG/HH_GRP_PRTA
/MSG/HPREM_DST
/MSG/HU_HPRTDETV
/MSG/HH_GRP_S_DA
/MSG/HPRT
/MSG/HUBNPRT_AL
/MSG/HH_GRP_SYN
/MSG/HPRT_ER_AL
/MSG/HUGRP_F_C
/MSG/HH_GRP_VL
/MSG/HPRT_EXCL
/MSG/HUGRP_HD
/MSG/HH_PISECACC
/MSG/HPRT_HD
/MSG/HUGRP_SUB

/MSG/HH_PISECGRP
/MSG/HPRT_LUD
/MSG/HUGRPDET
/MSG/HH_PREM_DST
/MSG/HPRT_PART
/MSG/HUPRMPRT_AL
/MSG/HH_PRT
/MSG/HPRT_RDC
/MSG/HUPRTDET
/MSG/HH_PRT_ERAL
/MSG/HPRT_REINS
/MSG/HUPRTDET_VL
/MSG/HH_PRT_EXCL
/MSG/HPRT_RIC
/MSG/HUPRTOBJ_AL
/MSG/HH_PRT_HD
/MSG/HPRT_RIC_D
12.11 Monitoring
Use
You use monitoring processes to identify critical situations during background processing at an early stage. You
can use the Computing Center Management System (CCMS) to monitor the critical parameters of the central
processing unit, memory, and database. However, we recommend you use SAP Business Process Monitoring
(BPM) so that you can react explicitly at program level to error situations, such as program terminations.
Prerequisites
You have configured Solution Manager in full. You have also mapped the business processes being monitored
(chain of background jobs) in Solution Manager. SAP also offers a Solution Manager Preparation Service
(SMPS). For more information, see SAP Service Marketplace at http://service.sap.com/bpm.

Features
Monitoring is not just restricted to programs in the SAP namespace - you can also monitor customer-specific
programs. We recommend you define program terminations or individual job terminations during parallel
processing as errors.
In Solution Manager, you can select the program or job name as a criterion. In the case of programs started in
series, you should use the program name. However, in the case of programs started in parallel, you should use
the job name because the program name of the parallel framework is already assigned (“PBANK*” or similar).
The job name is assigned generically but contains a fixed section. For example, the job name of the RM
combined background job is E:/MSG/HGESB1001500802111#00001. The part /MSG/HGESB is a fixed
component of all created jobs and can be used as an ID with the placeholders *. We recommend the form
*/MSG/HGESB*.
You find the program names in the task list in Schedule Manager. You can find job names by executing a run in
transaction SM37.
12.12 SAP NetWeaver Business Client Applications
Use
SAP NetWeaver Business Client (NWBC) applications support you in the management of reinsurance entities
(such as loss, loss group, and object management) and are based on a floorplan for overview pages (OVP)
using generic user interface building blocks (GUIBBs).
Prerequisites
● Before you can use the applications, you have to activate the corresponding HTTP services for SAP
Reinsurance Management for SAP S/4HANA in parallel to the services for operating SAP NWBC. You use
transaction SICF to do this.
● You have assigned the new NWBC applications to the corresponding PFCG roles.
For more information about the structure of the user interface and about which functions are available to
control and manage applications and tables, see the following:
● Structure of the User Interface [page 778]

● Structure of a Search Screen [page 778]
● Control of Applications and Pages [page 779]
● Functions for Controlling Applications [page 780]
● Functions for Managing Tables [page 781]

12.12.1 Structure of the User Interface
To ensure a consistent appearance, the user interface is structured in a similar way in all FS-RI applications that
are based on a floorplan for overview pages:
● The system displays a description of the current process in the title bar. A distinction is made between:
○ Managed processes: <Application>: <Key Information> - <Step XY>
○ Administration: <Entity> - <Unique ID> - <Additional Information>
○ Evaluations: Evaluation: <Application>
● The toolbar is located below the title bar. Depending on the process, the pushbuttons on the left side of the
toolbar provide different functions that you can use to control the process flow. For an overview of the
available functions, see Functions for Controlling Applications [page 780]. The pushbuttons Personalize
and Help are also available on the right side of the toolbar. You can use these to call the personalization
editor or the application help (Help Center or Display Quick Help).
● The system displays messages below the toolbar.
● You can use the Display Message Log pushbutton to show or hide current messages and to get an overview
of all the messages that have been returned.
● Data that belongs together is grouped on each page in “areas”. The areas that are displayed is determined
by the selected application. You can expand and collapse areas. Areas that already contain data or that
contain required entry fields are displayed already expanded. Some areas are also subdivided into
“sections” in order to structure the data more clearly.
12.12.2 Structure of a Search Screen
Context
In many of the applications that you can use in the FS-RI system, the search screen is the starting point for
displaying or editing business objects or for starting the loss management processes. You can use the search
screen to navigate from the FS-RI system to the different applications (such as Object Management, Loss
Management, Loss Group Management). You can also enter different criteria on this screen to search for
specific entities (such as object, loss, loss group). You can then start the required application directly from the
selected search result.
The search screen is structured as follows.
Navigation to Entities
If you choose the You can also pushbutton in the toolbar and select an entry, you can branch directly to the
corresponding application.
Search for Entities
● Here you can select different search criteria and operators based on which you can search for specific
entities. The plus and minus pushbuttons enable you to add or remove rows in your search query. You can

choose the Find, Delete Entries and Reset to Default pushbuttons to start or delete the search or to restore
the default settings.
● If you want to shorten the wait time during a search, you can define the maximum number of hits to be
displayed by the system in the Maximum Number of Hits field.
● You can save a search query that you entered if you want to use it again at a later date. To do this, enter a
name for the search in the Save Search As field and choose Save.
● You can open any search queries that you saved under Search Criteria in the Saved Searches field. If you no
longer need a search query, you can remove it by choosing the Delete Search pushbutton.
Display the Search Results
The system lists the results of the search that you triggered from the Search Criteria in the lower part of the
search screen.
It displays the number of results in the title bar of the Results List. For more information about the functions of
the results list, see Functions for Managing Tables [page 781].
12.12.3 Control of Applications and Pages
The search screen remains open in the browser for the entire time that you are executing processes in the FS-
RI system. The system opens a new page for each application that you start from the search screen. You then
work in this application on this new page.
Main Page
For information about how the title of the main page is structured, see Structure of the User Interface [page
778].
Each main page is divided into areas. You can expand and collapse areas. Areas that already contain data or
that contain required entry fields are displayed already expanded.
You can use the navigation tree to navigate between the main pages.
You can navigate from a main page to the corresponding detailed page using a link.
Detailed Page
The title of the detailed page is composed as follows: <Title of Overlying Main Page> - <Title of Detailed Page>.
When you navigate to the processing page for activities, for example, the title is “Loss: 105053, Material Error
Activities”.
There is a text row below the toolbar that indicates which detailed page you are on within the application. This
text row is composed as follows: <Loss Management Level (as a link)> > <Entity Number/Text>
If you are on the detailed page for an FGU movement, for example, the text row is “FGU Movement > Account
208400”. You can use this text row to return to the overlying main page (in our example, this would be the main
page for FGU movements).

As is the case with the main page, the detailed page is also divided into areas.
You can use the navigation tree to navigate between the entities of a detailed page (in our example, you can
navigate between different FGU accounts).
 Note
For more information about navigating between main pages and detailed pages, see Functions for
Controlling Applications [page 780].
12.12.4 Functions for Controlling Applications
As described under Structure of the User Interface [page 778], the toolbar on the left side provides different
pushbuttons for executing control functions within an application.
The functions are active (in other words, the corresponding pushbuttons are displayed) only if they are
intended for the corresponding application.
The following functions are available:
General Functions
● Cancel: The system cancels the processing of the application and returns to the overlying page. You can
decide whether you want to keep your changes. The system switches from change mode to display mode.
● Edit: The system switches from display mode to change mode.
● History Mode: The system displays the historical statuses for an entity. For more information about the
history mode, see History Mode [page 671].
● Navigation: You can show or hide the navigation tree.
● Loss Figures: You can branch directly to the evaluation of the loss figures. The loss figures are evaluated for
the selected loss.
● Save: The system saves the current status of your work.
● You can also: You can branch directly to the corresponding application.
● Page: If you have hidden the navigation tree, you can switch to the other pages using this selection list.
Specific Functions
● Finalize: You can finalize the preview accounts for the current open activity for the loss by choosing this
pushbutton. The system then creates final FS-RI accounts from the preview accounts that are split and
released at the same time, meaning that they are posted to the current account.
● Calculate: You can trigger the calculation of result-independent conditions with the category "COM"
(commission) and "OTHER” (other) again for the existing preview accounts.
● Save and Back: The system saves the current status of your work on the detailed page and returns to the
overlying page.

● Tax Calculation: The system calculates the tax portions based on the Customizing settings of the existing
preview accounts and displays these at preview level. The calculation results are created as new postings
for the preview accounts being processed.
● Generate Preview: You can generate a preview for a loss and the current open activity that shows in
aggregated form what you have paid or reserved for a loss.
● Back/Continue: You can navigate between the entities on the corresponding processing page.
● Completed: You can navigate from the processing page back to the main page.
● Cedent: You can use this selection list to navigate between the different cedents.
12.12.5 Functions for Managing Tables
The following functions in the FS-RI system support the management of tables:
● Find: You can search for specific table entries by entering search criteria. The system displays the number
of matches found next to the Filter By field and marks these in color in the results list.
● Export to Spreadsheet: You can display results in a Microsoft Excel document.
● Personalize: You can configure the layout of the table to meet your own needs.
● Maximize: You can expand or minimize the table.
12.12.6 Configuring Web Dynpro Applications and SAP

NetWeaver Business Client
If you want to use NWBC applications, you have to make the following settings:
1. Install and configure SAP NetWeaver Business Client according to the Installation Guide.
2. Set up SAP NetWeaver Business Client according to the SAP NetWeaver Business Client Administration
Guide.
3. Activate the required http services in transaction SICF. For more information, see the corresponding
system documentation.
You need the following http services for the SAP NWBC applications for loss and object management:
● /sap/bc/webdynpro/msg/82_RL_MGMT_OVP_WA
● /sap/bc/webdynpro/msg/82_RLG_MGMT_OVP_WA
● /sap/bc/webdynpro/msg/82_RL_OVW_OVP_WA
● /sap/bc/webdynpro/msg/82_RO_MGMT_OVP_WA

Important Disclaimers and Legal Information
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.
Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

782 PUBLIC Important Disclaimers and Legal Information
Important Disclaimers and Legal Information PUBLIC 783
www.sap.com/contactsap
© 2018 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. The information contained herein may be changed
without prior notice.
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 are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP 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.
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. All
other product and service names mentioned are the trademarks of their
respective companies.
Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.
THE BEST RUN

SAP Reinsurance Management For SAP S - 4HANA PDF

Uploaded by

Document Information

Original Title

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

SAP Reinsurance Management For SAP S - 4HANA PDF

Uploaded by

Copyright:

Available Formats

USER GUIDE | PUBLIC

Document Version: 3.0 – 2018-07-27

SAP Reinsurance Management for SAP S/4HANA

THE BEST RUN

1 SAP Reinsurance Management for SAP S/4HANA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

SAP Reinsurance Management for SAP S/4HANA

5 Basic System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

SAP Reinsurance Management for SAP S/4HANA

6 Current Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

7 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

SAP Reinsurance Management for SAP S/4HANA

8 Information System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

9 Background Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

SAP Reinsurance Management for SAP S/4HANA

11 Set Company Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

12 Cross Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

SAP Reinsurance Management for SAP S/4HANA

SAP Reinsurance Management for SAP S/4HANA

The following table explains the key features available:

Key Features Use

It is also used to group together policies for collective rein­

The system uses the rules specified in the reinsurance pro­

SAP Reinsurance Management for SAP S/4HANA

This feature is also used to distribute accounts delivered on

There is also an integrated function that distributes the ac­

The accounting function also creates the postings for the

SAP Reinsurance Management for SAP S/4HANA

● Query for Summary of Accounts

Query for Summary of Accounts [page 13]

2.1 Cubes and Queries for Account

2.1.1 Cube for Summary of Accounts

Technical Name /MSG/I_ACCOUNTINGRESULTC

View type Composite, Cube

Release status Released

SAP Reinsurance Management for SAP S/4HANA

Authorization Object Check Condition Field Value Description

SDDLVIEW Check whether the Authorization object

Authorization Object Check Condition Field Value Description

/MSG/A_ACC Check whether the Authorization object

BUKRS Company codes of Company code

SAP Reinsurance Management for SAP S/4HANA

/MSG/R_VTG Treaty number of the Treaty number

This view is built on the following business objects:

Main Input Parameters

● Exchange date (P_ExchangeDate)

Measures and Attributes

● Original amount (OriginalAmount)

SAP Reinsurance Management for SAP S/4HANA

● Account status (StatusCode)

2.1.1.1 Query for Summary of Accounts

Technical Name /MSG/C_ACCOUNTINGRESULTQ

View type Consumption, Query

Release status Released

SAP Reinsurance Management for SAP S/4HANA

Authorization Object Check Condition Field Value Description

SDDLVIEW Check whether the Authorization object

Starting the Query

● Exchange date (P_ExchangeDate)

SAP Reinsurance Management for SAP S/4HANA

Query Results and Data Analysis

● Original amount (OriginalAmount)

You can refine your data analysis using a variety of attributes:

● Account status (StatusCode)

It is also used to group together policies for collective rein

The system uses the rules specified in the reinsurance pro

There is also an integrated function that distributes the ac