Migration Interface Documentation for SAP Reinsurance ...

Migration Interface Documentation

Document Version: 1.0 – 2018-07-27

PUBLIC

Migration Interface Documentation for SAP Reinsurance

Management 8.0 FPS02 for SAP S/4HANA

Professional Underwriting Management Application

of 12

1 Contents

1 Contents 2

2 Document History 3

3 Glossary 4

4 Introduction 5

5 Migration 6

5.1 Periods 7

5.2 Number Assignment 7

5.3 Partners Involved 7

5.4 Split Information and Main Structural Characteristics 7

5.5 Exposures 8

5.6 Values and Value Types 8

5.7 Currencies and Amounts 9

5.8 Sublimits and Deductibles 10

5.9 Premiums 10

5.10 Premium Postings 10

5.11 LUDs 10

5.12 Program Business 10

5.12.1 Exposure Extracts 10

5.13 Underwriting Notes 11

5.14 Reminders 11

5.15 Finalize 12

5.16 Checkmatic 12

5.17 Customer-Specific Extensibility 12

5.18 Authorizations 12

of 12

2 Document History

Version Date Change

1.0 2018-07-27 Initial Version

of 12

3 Glossary

Term Description

PUMA Professional Underwriting Management Application

FPM Floorplan Manager für Web Dynpro ABAP ©SAP

RFC Remote Function Call ©SAP

UIBB User Interface Building Block ©SAP

DDIC ABAP Data Dictionary ©SAP

IP Individual Policy

IPP Individual Program Policy

SPA Special Acceptance

MPP Master Program Policy

API Application Programming Interface

of 12

4 Introduction

You can use the migration interface to create your existing policy data set in PUMA. This document describes the general procedure, special cases and restrictions relating to the migration process. This document also shows which processing steps can be necessary after a policy has been created using the migration interface.

During the migration process, policy data is combined in a comprehensive DDIC structure, subject to plausibility checks and created using a method call. A policy is created in full. If the supplied data is incorrect or incomplete, a policy is not created in the database. The migration process consists of the following steps:

1

•RFC Checks and Transformation

•Required field checks and consistency checks on the supplied structure /UPE/RP_C_POLICY_MIGRATION and transformation into the relational data model.

2

•API Checks and Checkmatic Checks

•The supplied data is subject to further business-motivated checks in the relational data model.

3•Data Save

•The data is saved in the database.

4

•Further Processing of the Created Data via PUMA Interfaces

•Customer-specific further processing of the data. This includes the completion of the policy or the creation of premium groups and installments. This step is not part of the delivered migration interface.

of 12

5 Migration

To migrate policies, you use the class /UPE/CL_UI_RP_C_POLICY_MIGRATE. This class checks the

consistency of the supplied data and performs the mapping to the relational data model of PUMA.

Example: Call migration

DATA: lr_migration TYPE REF TO /upe/cl_ui_rp_c_policy_migrate,

ls_migration TYPE /upe/rp_c_policy_migration,

lr_output TYPE REF TO data,

lt_return TYPE bapiret2_t.

FIELD-SYMBOLS: <ls_output> TYPE /upe/rp_c_policy_migration_out.

lr_migration = NEW #( ).

lr_migration->execute(

EXPORTING

ir_input = REF #( ls_migration )

IMPORTING

er_output = lr_output

et_return = lt_return ).

ASSIGN lr_output->* TO <ls_output>.

The data is passed to the class using the DDIC structure/UPE/RP_C_POLICY_MIGRATION. The structure

itself is documented, contains documented data elements and is aligned to the user interface of PUMA. The supply of the data in the structure must fit the business context.

Example

In the User Interface Building Block (UIBB) Exposure Information of the exposure type “Directors and Officers”, the fields Currency, Market Capitalization Amount and Total Assets Amount cannot be edited until you have selected a type of ownership. Consequently, it is not useful to supply these fields in the migration process if the type of ownership is not supplied.

Caution

Despite intensive checks in the RFC layer, CHECK_INTERFACE of the API classes and Checkmatic, the

number of possible variants of supplied data means that not all incorrect data specifications result in an error message and are excluded. Especially in scenarios such as the above, it may be that data is not created and a corresponding message not issued if the supplied data is not plausible in accordance with the business definition.

The result of the migration is a table with error messages in the exporting parameter ET_RETURN and an

output structure that returns the created policy ID and group ID (only for MPP) in the case of successful migration.

of 12

5.1 Periods

You can use the migration interface to supply policy sections and participations with several periods.

5.2 Number Assignment

A fundamental distinction is made between number assignment using number range objects and consecutive numbering. In PUMA, many IDs are assigned automatically, if requested. Automatic number assignment is requested, as is usual in FS-RI, by specifying "<INTERN#> [consecutive number for tabular entries]" in the ID field.

Caution

To avoid issues with the uniqueness of entries, you must supply all the entities of a type with different, consecutive IDs (e.g. all exposures of the entire set of policies, all sublimits/deductibles of the entire policy).

For the migration, you must supply all the entity IDs that are not associated with a number range object with the above-defined format for internal number assignment. This makes sure that migrated entries are not differentiated from entries that are entered manually on the user interface.

For entity IDs associated with a number range object, the ID is assigned either manually using the number range rules or also automatically using the above supply method.

An exception to this rule are the result-independent conditions, for which a consecutive ID is automatically assigned when no value is supplied.

5.3 Partners Involved

To assign cedent and broker to a policy, you must supply this data with the corresponding role code in the

table/UPE/RIPOL_INV_PARTY_DATA_ITAB (INVOLVEDPARTY_DATA) in the policy header.

Role Role Code (field ROLECODE)

Broker XRVB03

Cedent XRVB01

5.4 Split Information and Main Structural Characteristics

The main structural characteristics are saved in the policy section header, the split information at period level.

These two pieces of information are combined when supplied to the migration interface. The split

information is supplied at period level. The indicator MAININDICATOR flags split information as the main

structural characteristic of the policy section header. There are no separate fields at the policy section header level.

Caution

You need to make sure that the MAININDICATOR is supplied in all policy section periods for the same split

entry.

of 12

5.5 Exposures

Exposures have period-dependent and period-independent data. Explicit handling of period-independent data (exposure header data) should not be performed in the migration interface. Control is based on data

supply at period level using the field INTERNALID in /UPE/RP_C_EXP_B_DATA (CREATEBASICDATA).

Caution

Since all exposure information of the different exposure types is stored in the same database table, when exposures are supplied for a policy, a unique ID must be supplied for each exposure, independently of the exposure type. The rules for internal/external number assignment explained above apply.

To assign several exposure periods to an exposure header, the same exposure ID must be supplied in several policy section periods. Note that only exposures of the same type with identical Ids are supplied, since the exposure type depends on the exposure header and is thus defined by the first exposure entry processed.

Premiums, sublimits and deductibles can refer to exposures and their coverages or to locations. The reference to exposures and their sections is created by the supplied IDs.

Note

Sublimits and deductibles can refer to exposures and their coverages. The reference to the exposure is

created by the specification of the exposure ID in the field INTERNALID of the structure

/UPE/RP_C_SUB_DED_EXP_B_DATA (EXPOSUREBASICDATA). A coverage that exists in this exposure can

be created by specifying its coverage ID in the field ID of the structure/UPE/RP_C_SUB_DED_COV_DATA

(COVERAGEDATA).

5.6 Values and Value Types

The values of the Values page in PUMA are stored in value types of FS-RI Risk Manager (Non-Life). The migration interface hides this complexity and, instead, provides business structures. The consistency of the supplied values is ensured by checks. The valid supply variants are defined in the structure documentation

for /UPE/RR_C_PRT_JRN_VALUES_MIG ("Migration Participation Value Types") and

/UPE/RP_C_SEC_JRN_VALUES_MIG ("Migration Policy Section Value Types"). The value type calculation

is part of the migration. For this reason, percentage rates and dependent amount fields, for example, should not be supplied at the same time. The fields are calculated in accordance with the defined rules and are consistent after migration.

You may only supply the values for the policy section period if at least one participation period is supplied at the same time for the policy section period. Depending on the cedent type of the policy section, different value types are created in PUMA when the first participation for a policy section is created.

The currency of the policy section values is defined by the field LIABILITYCALCULATIONCURRENCY of the

structure for policy section period data /UPE/RP_C_SECTION_JRN_001 (SECTION_JOURNAL_DATA) (X

structure: /MSG/HX_POS-CURR).

The currency of the participation values is defined by the field LIABILITYCALCCURRCODE of the structure

for participation period data /UPE/RR_C_ASSUMED_PRT_JRN (PRT_JRN_DATA) (X structure:

/MSG/HX_PRT-CURR).

of 12

5.7 Currencies and Amounts

Either the field CODE or ISOCODE can be supplied for currencies in interfaces. Note that you must use the

field CODE in the migration interface.

Each amount has its own currency fields. There are also “standalone” currency fields, such as the leading currency in the policy section header. The currency fields for each amount field in the interfaces are defined by the FS-RI standard for interfaces. This means that different currencies can be supplied for each amount. PUMA currently does not fully support different currencies for individual amounts.

Caution

Only one currency may be used throughout for each policy section period and participation period. This currency (and the exchange rate) must be defined in the currency split of the associated policy section period.

Exposures are the exception to this rule. Here you can also specify amounts and currencies, depending on the type of the exposure. These currencies are neither linked to the currencies defined in the currency split nor must they match the policy section period currency. Nevertheless, the same currency must be supplied within a structure for exposure information. For example, you can supply different currencies in the fields

CURRCODE, MARKETCAPITALAMTCURRCODE and TOTALASSETSAMTCURRCODE in the structure for

exposure information /UPE/RP_C_EXP_DRF_INF_DATA, since there are no checks on the sameness of the

fields.

Caution

Supply of a different currency on the user interface (UI) of PUMA is not supported. Here too, the same currency must be used for all fields of the same business context.

X fields are defined for each amount. They enable you to set the amounts to “null”, meaning “not defined”. The FS-RI interface definition provides for the consistent handling of the X fields only at Create. When creating new entities, supplying the X field without a value will supply an amount with “null”. At update operations after the migration, via API calls or the user interface of PUMA, the meaning of the X field reverts to the normal supply indicator. Thus, if an update operation changes an amount, this amount cannot be flagged again as “null”.

Note

Since SAP Web Dynpro ABAP or FPM does not distinguish between “null” meaning “not defined” and “null” meaning the amount “0”, you need to supply all X fields for amounts with “X” and all currency fields with the appropriate currency when migrating.

When you supply amounts with a different number of decimal places, the usual SAP rules for currency handling apply.

Examples:

Currency Supplied Value Result on UI

EUR: 2 decimal places '38500' 38,500.00

JPY: No decimal places '50000' 5,000,000

of 12

5.8 Sublimits and Deductibles

Sublimits and deductibles possess a common basis table and must thus be supplied with consecutive IDs.

Caution

You should not supply sublimits and deductibles with the same ID.

5.9 Premiums

Premiums can be based on different premium bases. The availability of the individual (shipped) premium bases varies with the premium input data. For example, you can only choose exposure type-specific premium bases if an exposure of the appropriate type is assigned to the premium.

5.10 Premium Postings

After successfully migrating a policy, you can generate premium postings for each participation with the

help of the RFC module /UPE/RR_P_A_P_PRM_POST_IN. You can then adjust the posting data with the

RFC module /UPE/RR_U_A_P_PRM_POST_IN.

5.11 LUDs

In the case of non-proportional participations, the LUDs of rank 1 and 2 are automatically provided from the supplied values and should not be supplied.

The LUD with rank 1 is assigned the value from the attachment amount for reinsurance and the LUD with rank 2 is assigned the limit amount for reinsurance.

5.12 Program Business

The migration interface is designed to create IPs and MPPs. When creating IPPs and SPAs, the dependencies to the associated MPP must be stored correctly.

Note

For the migration, you must use the function module /UPE/RP_C_POLICY_FROM_MPP to create IPPs and

SPAs (including the creation of policy sections and participations). You can use the shipped update interfaces to adjust the created IPPs and SPAs to satisfy requirements. The use of these interfaces ensures that all the dependencies between the original MPP and IPP/SPA are provided correctly.

5.12.1 Exposure Extracts

You can supply exposure extract data for each policy type except IP. The meaning of the extracts depends on the policy type. In MPPs, the exposure extract data represents the exposure information that may be created from dependent IPPs and SPAs. When an IPP section or SPA section is created, this information is copied from the corresponding MPP section into the exposure extract data of the created IPP or SPA. Checks are always performed against the exposure extract data of the own policy section and not against the exposure extract data of the MPP. Exposure extract data can be different between MPP and its dependent IPPs and SPAs, since the valid version when creating an IPP or SPA is copied from the MPP. Further synchronization does not take place. Thus, you can also supply different data via the migration interface. Note that you need to ensure the business validity of the data.

of 12

5.13 Underwriting Notes

You can refer to entities of the new created policy using the underwriting notes created by the migration

process. To do this, specify the business key of the referenced entity in the structure /UPE/ENTITY_KEY

(ENTITYKEY) of the underwriting note. You must fill the fields of the ENTITIYKEY dependent on the

ENTITYTYPECODE:

Type of Entity Entity ID Parent Entity ID Period

Policy Policy ID

Policy Section Policy Section ID Policy Section Period

Participation Participation ID Participation Period

Exposure Exposure ID Policy Section ID Policy Section Period

Exposure Coverage Coverage ID Exposure ID Policy Section Period

Deductible Deductible/Franchise ID Policy Section ID Policy Section Period

Sublimit Sublimit ID Policy Section ID Policy Section Period

Underlying Information Underlying Information ID Policy Section ID Policy Section Period

5.14 Reminders

You can refer to entities of the new created policy using the reminders created by the migration process. To

do this, specify the business key of the referenced entity in the structure /UPE/ENTITY_KEY (ENTITYKEY)

of the reminder. You must fill the fields of the ENTITIYKEY dependent on the ENTITYTYPECODE:

Type of Entity Entity ID Parent Entity ID Period

Policy Policy ID

Policy Section Policy Section ID Policy Section Period

Participation Participation ID Participation Period

Exposure Exposure ID Policy Section ID Policy Section Period

Exposure Coverage Coverage ID Exposure ID Policy Section Period

Deductible Deductible/Franchise ID Policy Section ID Policy Section Period

Sublimit Sublimit ID Policy Section ID Policy Section Period

Underlying Information Underlying Information ID Policy Section ID Policy Section Period

of 12

5.15 Finalize

The migration process does not finalize policies automatically. Use the function module

/UPE/RP_P_FINALIZE_POLICY to finalize policies.

Caution

A number of status-dependent checks are not performed until completion. Data, which prevents successful completion, can be supplied via the migration interface.

5.16 Checkmatic

The Checkmatic checks of PUMA including FS-RI Risk Manager (Non-Life) are run at migration. If need be, you can switch the Checkmatic context to migration. This means you can define migration-specific checks that are not run in the normal context of PUMA. You switch the context by means of the following statement (for the current mode):

/UPE/CL_CHECKMATIC=>SET_MIGRATION_MODE( )

The statement must be called before the first generation of Checkmatic, ideally when the program is started.

Caution

If you switch the context, the standard checks will no longer run at migration. It is recommended to also perform the Checkmatic checks of FS-FI and PUMA when migrating to the production system. Note a corresponding (customer-specific) Checkmatic context.

5.17 Customer-Specific Extensibility

The migration follows the usual extensibility concept. Fields of the type BAPIPAREX_T are defined in key

places of the structures EXTENSION_IN (convenience layer: EXTENSIONIN) defined for the migration.

The method DO_CUSTOMER_PROCESSING of the class /UPE/CL_API_MIGRATION has an empty

implementation. If customer-specific actions are required at migration, you need to redefine this method in a derivation. Afterwards, the corresponding actions can be performed directly on the X tables of the API from

the contents of the EXTENSION_IN. If you redefine the API class, you must also derive the RFC class

/UPE/CL_UI_RP_C_POLICY_MIGRATE (if used) and assign an instance of the derived class to the

attribute MR_API_INSTANCE in the CONSTRUCTOR.

5.18 Authorizations

The migration class /UPE/CL_API_MIGRATION checks if the calling user is authorized to create a policy.

www.sap.com/contactsap

© 2018 SAP AG 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 AG. The information

contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain

proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP AG and its affiliated companies (“SAP

Group”) for informational purposes only, without representation or

warranty of any kind, and SAP Group shall not be liable for errors or

omissions with respect to the materials. The only warranties for SAP Group

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 AG in

Germany and other countries. Please see www.sap.com/corporate-

en/legal/copyright/index.epx#trademark for additional trademark

information and notices.

Material Number: NA

Migration Interface Documentation for SAP Reinsurance ...

Documents

Transcript of Migration Interface Documentation for SAP Reinsurance ...