Generations in FS-PM - SAP Help Portal · Generations in FS-PM Contents: ... 5 3.1.2 Generations in...

Author: Christian Mathias Mül-ler

Generations in FS-PM


Contents:

1 Disclaimer .......................................................................................................................... 4

2 Summary ............................................................................................................................ 4

3 Definition of Terms ............................................................................................................... 4

3.1 Generation ....................................................................................................................................................... 4

3.1.1 Generations in msg.PM ................................................................................................................................... 5

3.1.2 Generations in IBC ......................................................................................................................................... 6

3.2 Adaptor Stage .................................................................................................................................................. 8

3.3 Generation date (GENERATION_DT) ................................................................................................................... 9

3.3.1 What is it? .................................................................................................................................................... 9

3.3.2 Who has it? ................................................................................................................................................ 10

3.3.3 What determines its value? ............................................................................................................................ 10

3.4 Generation Determination Date (GENERATION_DET_DT) ..................................................................................... 11

3.4.1 What is it? .................................................................................................................................................. 11

3.4.2 Who has it? ................................................................................................................................................ 11


3.5 Generation flag (GENERATION_FG) .................................................................................................................. 13

3.5.1 What is it? .................................................................................................................................................. 13

3.5.2 Who has it? ................................................................................................................................................ 13


3.6 Effective Date (EFFECTIVE_DT) ........................................................................................................................ 14

3.6.1 What is it? .................................................................................................................................................. 14

3.6.2 Who has it? ................................................................................................................................................ 14


4 Sample products................................................................................................................ 15

4.1 Sample products with generations .................................................................................................................... 15

4.1.1 Life ........................................................................................................................................................... 15

4.1.2 P&C .......................................................................................................................................................... 16

4.2 Sample products with adaptor stages ............................................................................................................... 16

5 Navigation tree and generations ........................................................................................... 17

6 General Rules .................................................................................................................... 18

7 New business and generations ............................................................................................ 19


7.1 New business................................................................................................................................................. 19

7.2 Create contract/coverage with different start ...................................................................................................... 21

7.3 Shift start of policy ......................................................................................................................................... 23

7.4 Shift start of contract/coverage ........................................................................................................................ 24

8 BP Change and generations ................................................................................................ 25

8.1 Include Contract ............................................................................................................................................. 25

8.2 Include Coverage ............................................................................................................................................ 26

8.2.1 GENERATION_FG of product not set .............................................................................................................. 26

8.2.2 GENERATION_FG of product set ................................................................................................................... 27

8.3 Product change .............................................................................................................................................. 27

8.4 Sales product change ..................................................................................................................................... 28

9 BP Universal Change and generations .................................................................................. 29

10 Generations in Releases before 4.5 ....................................................................................... 29

10.1 New Business ................................................................................................................................................ 29

11 Glossary ........................................................................................................................... 29

12 Terms English – German ..................................................................................................... 30


1 Disclaimer

This guide is not part of SAP product documentation. By using this guide, 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.

2 Summary

The goal of this document is to describe the behavior of FS-PM with respect to generations in order to pro-vide an understanding of all aspects of these topics.

This document describes what generations are and their associated technical fields. All business processes supplied by the standard where generations are of importance are worked through by example.

3 Definition of Terms

3.1 Generation

Generations of a product are similar to different versions of a product.

Insurance companies frequently introduce new versions of their products. Normally, the new versions of a product are provided for new business only and should not impact existing contracts of that product. As a re-sult, there may be several versions of a product and an existing contract is associated with one specific ver-sion.

Example: Blue Sky Insurance decides it is important to introduce a new clause to all new contracts of product A because of market pressures; however, contracts already in existence must not be changed. Product A is currently in generation (version) “1”. Blue Sky therefore introduces generation (version) „2“. Existing con-tracts continue to be associated with version „1“while new contracts are associated with version „2“.

From here on we will refer to different versions of a product as generations of a product.

Sometimes, changes to a product may be significant enough that one does not introduce a new generation of a product but a new product altogether. There is no clear way to decide when to introduce a new genera-tion of an existing product and when to introduce a new product. This decision is at the discretion of the one who defines the product.

Example: Blue Sky Insurance decides product A is not profitable enough; it needs to make product A more interesting for young customers. A few new clauses are added, some are removed, and the premium calcu-lation is changed. The decision is made that the changes are big enough to warrant the introduction of a new product B with these changes instead of introducing a new generation of product A. Product A is discontin-ued, Blue Sky Insurance no longer accepts new applications for contracts of Product A, but existing contracts will remain untouched.


Figure 1: Products and associated contracts at Blue Sky Insurance (business view)

At any given point, therefore, there are several products in existence at an insurance company, and several generations of each product. Contracts are associated to exactly one generation of one product.

One could argue that it should be possible to ignore generations altogether and consider every new version of a product a new product. However, the concept of generations is firmly rooted in the business. Frequently, customers may be offered to switch to a new generation of their contract’s products, or be switched automat-ically. This happens less often with new products.

An important concept of generations is that they have a validity – there is a begin and an end date associat-ed with each generation.

Example: Generation 1 of product A is valid from 01.01.2008 – 31.12.2008, while generation 2 of product A is valid from 01.01.2009 – 30.06.2010, and generation 3 of product A is valid from 01.07.2010 onwards.

We will try to clarify what this validity actually means in what follows.

3.1.1 Generations in msg.PM

In the following section is a description on details of the implementation of generations in the Product Man-ager msg.PM. Please note that other product engine needs not necessarily handle generations the same way; some may not even support generations.

A given product is composed of several product modules. Each product module is associated with a product module class; a product module class corresponds to exactly one entity in FS-PM1. Every product module class may be configured to be able to have generations.

At present, generations are supported only for the following entities:

/PM0/ABDAPOLICY / sales product,

/PM0/ABDAPOLPR / product,

1 There are some product module classes that are not mapped to FS-PM; for these, there is no correspond-ing FS-PM entity as it is only used by msg.PM internally.


/PM0/ABDACOVPAC / elementary product bundle,

/PM0/ABDACOV / elementary product,

/PM0/ABDACOVCP / elementary product calculation module.

A guiding principle is that generations may only occur on entities of the main axis.

In msg.PM, a few additional entities are customized as carrying generations (for instance, the premium enti-ty); however, this is due to historical reasons. It was not possible to correct the customizing without signifi-cant disruption.2 Generations on these entities are definitely not supported.

In msg.PM, generations for a given product module may only be defined in an unbroken validity chain with no overlaps. This means that at any given time within the validity of the product, there is exactly one valid generation. The validity of the product is defined from the begin date of the first generation to the end date of the last generation. Begin and end date may be defined to be infinity and minus infinity, respectively.

Figure 2: Unbroken generation chain of product A

Example: Figure 2 display an unbroken generation chain. The chain would be invalid if generation 1 were to end on 30.12.2008 and generation 2 to begin on 1.1.2009 with no generation in between since then there is no generation valid on 31.12.2008.

In msg.PM the relations a product module has with other product modules is defined for each generation.

Example: Generation 1 may have clause Z as a child, while generation 2 has clause Z and W, and genera-tion 3 has only clause T as a child.

This also applies if the relation is to other product modules with generations. It is important to note here that the relations are defined from a product module generation to a product module.

Example: Generation 1 of product A defines elementary product H as child. Elementary product H has two generations. This means the following combinations may occur in a contract:

Product A, generation 1 and elementary product H, generation 1,

Product A, generation 1 and elementary product H, generation 2.

How the different combinations are formed for a given contract depends on the details of the business pro-cess.

3.1.2 Generations in IBC

The IBC (In-Force Business Configurator) is the single source of truth for FS-PM-related product data origi-nating from a product engine. The IBC implementation is independent of the product engine used.

In IBC, a product model is composed of “templates” very much alike to msg.PM product modules. However, there are no “generations” within the IBC. Templates can have validity, but there is no mechanism that as-

2 Cleaning up the customizing with respect to generations in msg.PM would lead to an invalidation of all test cases of the sample products and would make it technically impossible to perform an extended import. The situation was therefore left as it is.


signs two generations to the same product, since there is no entity called “product” in IBC. The IBC only knows templates.

Figure 3: Relationship between templates and generations of product modules

Example: In msg.PM, a product module of product module class “product” has been defined with three gen-erations, 1, 2 and 3. In the IBC, these two generations correspond to three separate templates with the va-lidity dates of generations 1, 2 and 3, respectively. Within IBC, there is no relationship between templates 1, 2 or 3.

In FS-PM, contracts are actually assigned to templates, not product module generations; that is, Figure 1 (the business view) corresponds to the technical view in FS-PM shown in Figure 4.

Figure 4: Technical relationship between product generations, templates and contracts

As stated before, only certain main-axis entities support generations; translated into the language of tem-plates and IBC, only templates of the following entities have a validity:

/PM0/ABDAPOLICY,


/PM0/ABDAPOLPR,

/PM0/ABDACOVPAC,

/PM0/ABDACOV,

/PM0/ABDACOVCP.

All other templates have unlimited validity.

In IBC, the validity is defined as the time between the “sales period from” and “sales period to” fields, defined on the template.

Figure 5: Validity of a template defined by the fields "sales period from" and "sales period to" in IBC.

3.2 Adaptor Stage

The adaptor stage is a concept within msg.PM that is used to enable changes to a product which should af-fect existing contracts. Adaptor stages – like generations – have a begin date and an end date (which may be infinite). Adaptor stages define the behavior of a product generation corresponding to an effective date.

An adaptor stage is always tied to a product generation, which means a product generation has one or more adaptor stages in msg.PM.

In msg.PM it is possible to change products arbitrarily from one adaptor stage to the next – one may change relationships, default values, value ranges, calculations, etc. However, FS-PM does not support changes of static data in adaptor stages. As a result, only changes concerning the internal details of a product are al-lowed, that is, changes to algorithms and calculation tables within msg.PM.


Figure 6: Adaptor stages for generations in msg.PM

Example: Blue Sky insurance decides that from 1.1.2010, the rating logic for product A, generation 1 will be based on a different algorithm. Therefore, they introduce a new adaptor stage 2 for generation 1 which uses the new algorithm. Any calculation calls to product generation 1 with an effective date larger than or equal to 1.1.2010 will now use the new algorithm.

A contract of product A, generation 1 is entered in new business at 1.1.2009. The old algorithm will be used for the calculation, since the effective date 1.1.2009 corresponds to adaptor stage 1. After a year, the premi-um is recalculated, this time the new algorithm is uses since the effective date 1.1.2010 corresponds to adaptor stage 2.

In FS-PM, adaptor stages are essentially invisible; IBC templates do not take them into account, nor are there any processes associated with it. There are no automatic adjustments to contracts with adaptor stages within FS-PM. It is a concept that is only relevant within msg.PM. Since it is relatively easy to accidentally create anomalous behavior of contract calculations and it is difficult to maintain, the concept of adaptor stag-es should not be used.

3.3 Generation date (GENERATION_DT)

3.3.1 What is it?

The generation date persists the begin date of the assigned generation of the relevant product module. The GENERATION_DT was introduced before the IBC’s existence. A key was needed to identify the proper gen-eration of a given product module a contract was assigned to. Every product module has an ID, and the begin date of the assigned generation was used as key to determine the assigned generation. This genera-tion begin date is written into the field GENERATION_DT. Since the template now holds this information and the key to a template is unique (since templates have no generations), the field should no longer be relevant for processing within FS-PM for all entities that have templates in the IBC. It should be kept only for conven-ience so that users may immediately display the sales date begin of the associated template in a contract in-stead of navigating to the IBC first.


The only entity for which the GENERATION_DT date is still required is /PM0/ABDACOVCP (Elementary Product Calculation Module) since there are no corresponding templates in IBC; the PM-ID and GENERA-TION_DT form the unique identifier.

3.3.2 Who has it?

All entities that support generations have the GENERATION_DT field:

/PM0/ABDAPOLICY,

/PM0/ABDAPOLPR,

/PM0/ABDACOVPAC,

/PM0/ABDACOV,

/PM0/ABDACOVCP.

3.3.3 What determines its value?

Once an instance of a generation-supporting entity is created (for example, a contract or a coverage in new business or a new coverage in business process change), the “sales date from” date of the assigned tem-plate is written into the field GENERATION_DT, regardless how the instance was created (it does not matter if it was created in new business, business process change or business process universal change, dialogue or background mode3). This value changes when a different template is assigned to the instance. It then con-tains the value of “sales date from” of the new template.

The process for /PM0/ABDACOVCP is different, since this entity does not have templates and it is created by the product engine. Here, the GENERATION_DET_DT (see below) is determined in the product engine during calculation and the product engine adapter determines the relevant GENERATION_DT from this in-formation and writes the GENERATION_DT into the proper structure.

Figure 7: Field GENERATION_DT ("Generation Date") displayed. Note this is an instance of /PM0/ABDAPOLPR assigned to the template displayed in Figure 5. The Generation Date contains the value of the field "sales period from" from the assigned template.

3 This is true only under the assumption that the GENERATION_DT was not supplied by the caller when call-ing a background BTX.


3.4 Generation Determination Date (GENERATION_DET_DT)

3.4.1 What is it?

This field is used to determine the relevant generation and to determine which templates are valid for the cur-rent process. The generation determination date is the central information used for automatic selection of the appropriate template. Please note that this only applies for the automatic selection of templates. The user may still manually override this automatic selection; however, this is considered an exception.

If the generation determination date is inside the validity period of a template (sales period from – sales peri-od to), the template will be displayed in the navigation tree.

3.4.2 Who has it?

All entities that support generations have the GENERATION_DET_DT field:

/PM0/ABDAPOLICY,

/PM0/ABDAPOLPR,

/PM0/ABDACOVPAC,

/PM0/ABDACOV,

/PM0/ABDACOVCP.


The value of the generation determination date is determined differently depending on the business process, the business transaction and details of the input data.

3.4.3.1 New business:

On the entrance screen of the business process new business, the user has the choice between three differ-ent modes of assigning the generation determination date. It can either be the application date, the policy start date or a manual date entered by the user. This date will be used throughout new business.

An exception to this rule is when using the business transaction “create contract/coverage with alternate start” and “shift contract/coverage start” within new business. There, the contract start date of the contract with different start date is the generation determination date for this contract.


Figure 8: Choosing the generation determination date in new business.

Figure 9: Manual assignment of the generation determination date in new business

The generation determination date is filled with the policy start date or the application date, depending on the source of the generation determination date. It is also possible to determine it manually if Manual Entry is se-lected as the source of the generation determination date.


Example: On 10.11.2009, sales agent X sold a contract of product A to a customer Y with start date 1.1.2010. On 15.11.2009, a new generation of product A is introduced, begin date 1.1.2010. The user wants to enter the contract into FS-PM on 1.12.2009. However, the contract of customer Y was with the old genera-tion. In this situation, the user selects “Application Date” as generation determination date in order to create the contract with the old generation. Had he selected “Start Date” as generation determination date, the con-tract would have been created based on the new generation of the product – which is not what the customer bought.

3.4.3.2 All other processes:

The generation determination date is identical to the effective date of the process.

3.4.3.3 General Remark

The generation determination date does not change after the instance has been created, unless one switch-es the assigned template during product change/sales product change or by shifting the begin date of the entity or its parent.

3.5 Generation flag (GENERATION_FG)

3.5.1 What is it?

The generation flag is a configuration parameter. The flag is relevant for all processes where a coverage bundle or coverage is to be included in an existing policy. It determines whether a new coverage is included based on the current effective date of the business process or based on the GENERATION_DET_DT of the father instance /PM0/ABDAPOLPR.

3.5.2 Who has it?

The GENERATION_FG field only exists on

/PM0/ABDAPOLPR.


The flag can take values 0 and 1. The value is set as during design time of the template and may not be changed during processing. For all processing, GENERATION_FG is a read-only parameter like customiz-ing.


Figure 10: GENERATION_FG as part of the product customizing in IBC.

3.6 Effective Date (EFFECTIVE_DT)

3.6.1 What is it?

The effective date of a process is the date at which the changes shall come into effect.

3.6.2 Who has it?

The effective date is not persisted in a contract since it is an attribute of the processing entity (a business transaction or time model function). Every processing entity of a contract has an effective date.


For dialogue business transactions, the effective date of the transaction is entered on the initial screen.


Figure 11: Effective date entered on initial screen

In background business transactions, the effective date is a parameter that needs to be supplied by the call-er. For time model functions this parameter is determined automatically by the time model function.

4 Sample products

4.1 Sample products with generations

4.1.1 Life

The behavior of the products is identical in all generations. These sample generations are only available from Release 5.1 onwards.

Sales Product “Live Capital/Leben Kapital”

Generation 2000: 1.7.2000 – 31.12.2006

Generation 2007: 1.1.2007 – 31.12.2008

Generation 2009: 1.1.2009 –

Product “Endowment Insurance/Erlebensversicherung” PE100

Generation 2000: 1.7.2000 – 31.12.2006

Generation 2007: 1.1.2007 – 31.12.2008

Generation 2009: 1.1.2009 –


Elementary Product „Endowment Insurance/Erlebensversicherung“ E100

Generation 2000: 1.7.2000 – 31.12.2008

Generation 2009: 1.1.2009 –

Product „Combined Insurance/Gemischte Versicherung“ PG100

Generation 2000: 1.7.2000 – 31.12.2005

Generation 2006: 1.1.2006 – 30.6.2009

Generation 2009: 1.7.2009 –

Elementary Product „Combined Insurance/Gemischte Versicherung” G100

Generation 2000: 1.7.2000 – 31.12.2004

Generation 2005: 1.1.20005 – 30.6.2008

Generation 2008: 1.7.2008 -

4.1.2 P&C

Generation 2000 of product PH0001 has a different set of elementary products than generation 2005. Oth-erwise, the behavior of the generations is identical.

These sample generations are available from Release 4.1 onwards.

Sales Product “Family Coverage/Familienschutz”

Generation 2000: 1.1.2000 –

Product “Personal Liability/Privathaftpflicht” PH0001

Generation 2000: 1.1.2000 – 31.12.2004

Generation 2005: 1.1.2005 –

Elementary Product “Children of Legal Age/Volljährige Kinder” EH0011

Generation 2005: 1.2.2005 – 31.12.2006

Generation 2007: 1.1.2007 -

Product “Livestock Ownership/Tierhaftpflicht” PH0002

Generation 2000: 1.1.2000 – 31.12.2004

Generation 2005: 1.1.2005 –

4.2 Sample products with adaptor stages

Elementary Product “Personal Liability/Privathaftpflicht” EH0010 within sales product “Family Cover-age/Familienschutz”, Product “Personal Liability/Privathaftpflicht PH0001”, Generation 2005.

There are three adaptor stages; the calculation of the second age group end is different in each adaptor stage:

Adaptor stage 1: 1.1.2005 – 30.6.2006; end age second age group = 60


Adaptor stage 2: 1.7.2006 – 30.6.2007; end age second age group = 63

Adaptor stage 3: 1.7.2007 - ; end age second age group = 67

5 Navigation tree and generations

If the generation determination date is inside the validity period of a template (sales period from – sales peri-od to), the template will be displayed in the navigation tree.

There is the possibility to display all templates (button “display all templates”) regardless of validity period.

Figure 12: Navigation tree with generation determination date = policy start date = effective date = 1.2.2005. The templates with the generation determination date inside the validity period of the tem-plate are displayed.

Figure 13: Button "display all templates"


Figure 14: All templates are displayed after activation of the button „display all templates“.

Note that the navigation tree uses the generation determination date from the initial screen for displaying val-id templates, not the effective date.

Figure 15: Navigation tree with generation determination date = application date = 17.2.2004, effective date = 1.2.2005. The templates with the generation determination date = 17.2.2004 inside the validity period of the template are displayed. Note that the displayed templates are different from Figure 12, which has the same effective date but a different generation determination date.

6 General Rules

The begin date of a main axis entity may not be smaller than the sales period begin date of the corresponding templates.4

The begin date of a main axis entity may be larger than the sales period end date

Any main axis entity not created in the context of new business ( and with GENERATION_FG of the product set to “false” if it is a coverage or coverage bundle) automatically uses the begin date of the entity as generation determination date. The entites manipulated by the business transactions “create with different start date” or “shift start date” obtain the generation determination date from their begin date as well.

The generation determination date may not be larger than the start date of the entity.

4 Without this restriction, a calculation will be attempted based on a date before generation begin. Msg.PM will generate an error is such cases.


Obligatory children are always created based on the generation determination date of their fa-ther. Children with minimum cardinality 1 with sales period outside the generation determination date of their father nodes are not obligatory.5

Processing is identical in dialogue mode and background mode. Note that it is possible to sup-ply BTX in background mode with generation determination date and generation date; there is no explicit check if the BTX dialogue allows changes to these fields. Therefore, supplying the fields GENERATIO_DET_DT and GENERATION_DT in a background call must not take place if the BTX does not support these changes as they are derived automatically.6

Handling of generation determination date entered in new business. The generation determina-tion date entered on the initial screen is used to display the navigation tree and all instances created during new business obtain this generation determination date. This does not apply to instances which were created with the BTX “Create with alternate start” or whose start date was shifted via “shift start”.

Note that the entity /PM0/ABDACOVPAC has not begin or end date, as it is only intended as a structuring layer.

7 New business and generations

7.1 New business

In new business, all templates are displayed according to the generation determination date set on the initial screen. All generation determination fields of all relevant newly created entities are filled the generation de-termination date set on the initial screen.

5 An exception to this rule is if the generation determination date of a contract is smaller than the generation date/sales period begin or larger than the sales period end of the associated product. In this case, the gen-eration determination date is set to the generation date of the contract in /PM0/CL_UBOI_POLPR_BADI~CREATE_UBOI_NODE so that obligatory children are determined based on the generation date. There are several other possiblilties how to handle this, but the algorithm described above is the current implementation.

6 Examples are in BP Change „Create contract“, „Create coverage“, and in BP New Business “Shift contract start” “Shift coverage start”. Note that for “Shift policy start”, supplying the generation determination date is allowed since in dialogue mode the generation determination date may be entered by the user.


Figure 16: New business initial screen. Note the generation determination date is based on the appli-cation date.

Figure 17: The generation determination date of the policy is 17.01.2004.


Figure 18: The generation determination date of the contract is 17.01.2004.

Figure 19: The generation determination date of the coverage is 17.01.2004.

7.2 Create contract/coverage with different start

If the business transaction “create contract with different start” is performed, the generation determination date is set to the begin date of contract with different starting date for this contract only. The point is to make this contract appear as if we had included the contract at a later date through a business process different from new business; as we already mentioned, in such a case, the generation determination date is always the effective date of the business process, which is also identical to the start date of the contract. The same rules apply to coverages with different start.

Note that there is no business transaction “create coverage bundle with different start”.


Figure 20: Including a contract with a different start date. We choose the appropriate template first.

Figure 21: Generation determination date for the contract with different start date is identical to the contract start.

Figure 22: We get the information that the start date of the contract with different starting date is out-side the sales period of the template. This is what we intended, so it is ok.


Figure 23: The persisted generation determination date is the contract start date of the contract with different starting date than the policy.

7.3 Shift start of policy

Figure 24: Generation determination date = application date = 17.12.2004, effective data = policy begin date = 1.2.2005

Figure 25: We can change what we entered on the initial screen. This results in a new generation de-termination date = 1.12.2004, new start date 1.12.2004. The levels below will be adjusted accordingly. The navigation tree reflects the new generation determination date.


7.4 Shift start of contract/coverage

If the business transaction shift start of contract is used, we want to have the same behavior as if the con-tract had already been created this way. This means that the generation determination date is identical to the shifted start date of the contract. The same rules apply for shift start of coverage.

Note that there is no business transaction “shift start of coverage bundle”.

Figure 26: Business transaction "shift start of coverage".

Figure 27: The generation determination date corresponds to the new start date of the coverage.


8 BP Change and generations

8.1 Include Contract

Figure 28: Business process change with effective date 1.6.2006. Note that we are offered the tem-plates whose sales period contains the effective date of the business process.

Figure 29: The contract is included with generation determination date = effective date = contract start date.


Figure 30: Obligatory children are automatically included with the generation determination date = ef-fective date = contract begin date.

8.2 Include Coverage

8.2.1 GENERATION_FG of product not set

Figure 31: Entering BP change, all templates matching the effective date are displayed - hence, we can include "EH011 Children of Legal Age 2007".


8.2.2 GENERATION_FG of product set

Figure 32: With the GENERATION_FG set, the templates displayed for inclusion of coverage match the generation determination date of the contract, 1.2.2006.

8.3 Product change

Figure 33: Product change; we are offered all templates whose sales period contains the effective date. There is no possibility to choose other templates.

Figure 34: After the product change, the generation determination date is set to the effective date of the business process.


8.4 Sales product change

Figure 35: For sales product change, there is the possibility to define whether or not the generation determination date may be entered manually (view /PM0/ABU_PSETTLE).

Figure 36: In sales product change, we can manually enter a new generation determination date; this is being used to select policy templates (instead of the “display all templates button”, which is not available here). This will only be converted to a new generation determination date of the policy if the policy begin changes.

Figure 37: Sales product change where we keep the start date of the policy. The generation determi-nation date stays the same, since generation determination date must be smaller or equal to the poli-cy start date; hence, effective date is not possible as generation determination date.


9 BP Universal Change and generations

The functionality is identical to “include contract/coverage” in BP Change.

10 Generations in Releases before 4.5

The “display all templates” button is not available as there are no templates available. Thus, it is not possible to include generations that are not valid at the effective date in business process change/ universal change.

10.1 New Business

Figure 38: Entering new business with generation determination date = application date = 17.12.2004, Policy start date = effective date = 1.2.2005. The navigation tree displays the generation according to generation determination date.

Figure 39: The generation determination date is set to the application date for the contract and cov-erage, as expected.

11 Glossary

BTX Business transaction

BP Business process


IBC In-Force Business Configurator

12 Terms English – German

Adaptor stage Anpassungsstufe

Generation determination date Generationsermittlungsdatum

Generation date Generationsdatum

Create contract with alternative start Vertrag anlegen mit abweichendem Beginn

Shift start of policy Policenbeginn verlegen

Shift start of contract Vertragsbeginn verlegen

Sales product change Verkaufsproduktwechsel

Product change Produktwechsel

Replacement business Ersatzgeschäft

Sales product Verkaufsprodukt

Product Produkt

Elementary product bundle Elementarproduktbündel

Elementary product Elementarprodukt

Elementary producyt calculation module Elementarproduktscheibe

In-Force Business Configurator Bestandskonfigurator

Generations in FS-PM - SAP Help Portal · Generations in FS-PM Contents: ... 5 3.1.2 Generations in...

Documents

Transcript of Generations in FS-PM - SAP Help Portal · Generations in FS-PM Contents: ... 5 3.1.2 Generations in...