Skip to Content

IFBC and the Characterstic Attributes

Motivation

From time to time the question arises how the Characterstic Attributes are (automatically) determined during In-Force Business Configurator (IFBC) import. In this document i want to shed some light on it.

What are Characterstic Attributes

The Characteristics - also known as Marks - have three special Attributes (don't mix them up with the static attributes of a template or the attributes of a channel model from PBT!) which are called Characterstic Attributes. These Attributes control the appearance and behaviour of the Characterstic on the User Interface. These Attributes are:

  1. Field Modifier (Mandatory Field, Recommended Field, Optional Field, Display, Hidden)
  2. Initial Value allowed (yes/no)
  3. Field is Used (yes/no)

These attributes do not have a counterpart in msg.PM resulting in the fact that they can not be imported. In principle, the settings have to be made after import in IFBC-UI for each and every template. You need to review and rework new templates (all Characteristics are new) and existing templates (if there are new Characteristics) after each IFBC import.

The screen shot below shows where the Characteristic Attributes can be maintained.

In order to reduce this manual effort after import, the system performs some rules and determines initial settings for the Characteristic Attributes.

How are the Characteristic Attributes defaulted

Since msg.PM does not provide Characteristic Attributes which simply could be imported to IFBC, the system performs some guessing based on data from PBT and other properties of current Characteristic.

The Field Modifier

The Field Modifier is defaulted with the content of the Field "Default" in the section "In-Force Business Configurator Information" on the "Attributes"-tab of an Attribute of a Channel Model in PBT (that's the tab where you also define "IFBC-Relevant" or "Persistence"). If the "Default" field is empty, which happens quite frequently, the system reads the content of the field "Field Modifier" on the same tab. This field usually is filled. The result is one ouf the following list:

  • Mandatory
  • Recommended
  • Optionald
  • Display
  • Hidden

If you want to have a look inside the coding, just go to method DETERMINE_CLASSIFIC_CD_REG in class /PM0/CL_ABU_IBC_DST_IMPORT. CLASSIFIC_CD is the internal name of what we call Field Modifier on the UI. This method is the implementation of the logic explained above.

The Flag Initial Value Allowed

Initial Value Allowed is relevant for Display and Hidden fields. In case no default value is configured (Default Settings), the Flag needs to be set to true because entering non initial values is not possible for Display or Hidden fields. This logic makes sense because it makes sure that such a Characteristic (display or hidden, no default value) will not be the cause not to be able to leave a screen and advance to the next screen.

The logic is implemented in method DETERMINE_ALLOW_INITIAL_FG_REG in class /PM0/CL_ABU_IBC_DST_IMPORT.

The Flag Field is Used

The third Characterstic Attribute, Field is Used, is derived from a couple of properties of current Characterstic. The flag equals true if one out of the following conditions applies:

  • There is a non initial ID of Value Range (List-ID) for the Characterstic
  • It is a non hidden Characterstic
  • There is a non initial Default Settings (Default Value)
  • Ther is at least one Value Range enty with non initial Lower Limit value

In other words: if the Characterstic is supplied with some non initial values (Lists, Defaults, Ranges), the product developer wants to make the Characterstic somehow relevant for the template.

The logic is implemented in method DETERMINE_RELEVANT_FG_REG in the same class.

What is the idea behind the logic

Basically it is about presetting or defaulting the Characteristic Attributes with reasonable values after import of new Characteristics. Keep in mind that the alternative is: setting no Characterstic Attributes at all.

The driving use case is the follwing: Imagine you have aready a couple of products in force and you are developing a new product. The new product requires a new Characterstic. You have already maintained the Channelmodel and added the Attribute in PBT. The channel model is used in the other products too. Now you do not want the new Characterstic to 'disturb' the existing products. In other words: by default the new Characterstic shall not show up on screens of old products - you want the Characterstic to be hidden for the majority of your products. Then you chose 'Hidden' for the field "Default" in PBT (see above) and you don't populate the properties "Default Settings", "Value Range ID", "Value Range" for the old products (as you can see you have no effort for the old products!). Then the new Characterstic will be set to 'not used' and you don't have any trouble with the old existing templates (at least from IFBC point of view). For the new template you need, of course, to adjust the Characteristic Attributes. In general the automatic algorithm won't find what you need. So manually overwrite the Characteristic Attributes according to your needs and protect them agains automatic overwriting by explicitly setting the checkbox "Char. Attrib. Import Lock".

As you can see, the behavior is optimized for the use case after initial setup of products. Keep the existing products and templates as stable as possible and concentrate on the new development or extension of products.

When will the logic be applied

Originally the defaulting logic did not exist at all. Customers complained about that because all templates with new Characterstics needed to be reworked manually. Consequently the defauilting logic has been added along with the option to select out of three flavors:

  • Always Complete - the Characteristic Attributes will be (re)determined for all Charactersistics of each and every template which has been touched during IFBC import. Characterstic Attributes of new Characterstics will be defaultet and Characterstic Attributes of existing Characterstics will be redetermined and in case there is no import lock set, overwritten. This is the default setting for imports from msg.PM.
  • Only Complete New Characterstics - As above; but Characterstic Attributes of existing Characterstics will not be changed. This is the default setting for imports from FS-PRO (because, in contrast to msg.PM, FS-PRO provides Characterstic Attributes and there is no need to redetermine them during import).
  • Never Complete - the defaulting logic will never be applied and the Characterstic Attributes of new Characterstics need to be maintained manually after import. Characterstic Attributes which have been maintained earlier will, of course, keep their values.

If you need a deviating default setting for "Determine Charac. Attributes" just define a new Variant and make it your default variant. We believe that the default settings on the selection screens for import and import simulation fit best for the use case mentioned above - evolutionary development of new products.

A Special Case


Sometimes there are Characterstics, which exist in IFBC but which are not part of current product delivery (compilate). Maybe they have been added manually to the template or they have been imported earlier. At a first glance this could be a candidate for deletion. However, the system is quite careful with respect to deletions. As a rule of thumb, the system just keeps the Characterstic as it is.

If all of the following condition apply:

  • the Characterstic exists in IFBC
  • the Cahracterstic is not part of product delivery (compilate)
  • the Attribute (PBT) is PM-relevant (note: not every IFBC-relevant Attribute is PM-relevant)

the system will set the Characteristics Attributes as follows:

  • Field Modifier = Hidden
  • Initital Value Allowed = TRUE
  • Field is Used = FALSE

to be continued ...

Tags:
Former Member