Change Management

Configure the Main Widget

 

Main Widget

  To configure the main widget, the Operation Form tab and the Field Assignment tab of the Change Management Configuration mask are used.

Select System > Change Management > Configuration.
The Change Management Configuration mask is opened.

 

The opened mask includes the following default configuration settings for relations and entities:

Relations:
  • Item-Application
  • Alternative Item Relation
  • Item-Item Relation, Bill Of Material (BOM)
  • Item -Document
  • Product Variant-Specification Constraint
Entities:
  • Application
  • Item
  • Product Component
  • Product Structure Element
  • Solution/Variant
  • Document
  • Classification
  • Requirement
  • Product Variant Specification
  In the Change Management configuration there's a principal difference between the main widget configuration settings for relations and entities.
The item-item relation (BOM) and the item as an entity are used as an example in the following description.
 

Entity

 
  In the Operation Form tab of the Change Management Configuration mask only the change operation entry will be used for the generation of the main widget. In the Change Operation column all possible change operations are listed. Only the "Replace 1:1-all" and the "Replace 1:n-all" are supported by monster masks for entities. This entry will be used to generate the menu for change operations during the specification of a change operation. Internally the change operation is mapped to a normal "Replace" operation where initially all existing locations are shown.
Entities do not have entries in the Field Assignment tab!
 

Relation

  In the Operation Form tab of the Change Management Configuration mask the form for the main widget, the lists for the sub widgets and the triggers are described.
 
 

The following entries have to exist in the columns of the Operation Form tab:

  • Change Operation column: The name of the change operation. A menu is opened with all possible names. Only Withdraw, Correct, Replace (1:1, 1:1-all, 1:n, 1:n-all, n:1) and Modify are supported by the main widget.

  • Main Form Parameter column: The parent entity name and the mask name which should be used.

  • Query Form Parameter column: The name of the QUERY-widget which will be opened virtually in the background. All visible fields will be copied as calculatory fields into the visible widget.

  • Origin Form Parameter column: The name of the ORIGIN-widget which will be opened virtually in the background. All visible fields will be copied as calculatory fields into the visible widget.

  • New Form Parameter column: The full parameter like it would be as sub widget for the DataView trigger iwf_frm_lis. This widget will be visible and in edit mode in the monster mask.

  • Copy Form Parameter column: Mask in which the record will be copied with the new values.

  • Pre Transition Userexit column: If something special should be done before transition.

  • Pre Transition Userexit Parameter column: The possible parameter for the pre transition userexit.

  • Post Transition Userexit column: If something special should be done after transition.

  • Post Transition Userexit Parameter column: The possible parameter for the post transition userexit.

  • Delete Userexit column: If something special should be done by deletion.

  • Parameter (Delete Userexit) column: The possible parameter for the delete userexit.
 
 

The following entries have to exist in the Field Assignment tab:

  • Position column: To define the order for the location filter fields on the MAIN-widget and fields inside the modal filter widget.

  • Source Field column: The data base representation of the calculatory fields.

  • Mask Type column: CURRENT means the field belong to the relation which will be changed. PARENT means the field belongs to the parent record of this relation.

  • Target Field column: The calculatory field used for the location filter fields on the MAIN-widget and fields inside the modal filter widget.
You must not use invisible fields for the field assignments!
 

Avoiding misrepresentation of the data in the main widget

 

To avoid the misrepresentation of the data with simultaneous aggregate and refine list in one widget, the ORIGIN-widget and the QUERY-widget are opened virtually in the background. The entries for the ORIGIN-widget and the result of the query are shown in calculatory fields in the foreground.
The foreground default-query-list and the foreground default-origin-list will be filled with calculatory fields for all visible fields of the virtually opened QUERY- and ORIGIN-widget. The foreground default-query-list has initially only the field with the selected flag. The foreground default-origin-list is initially empty. Both lists have to be placed in all main forms.
Because of the similarity of the different monster masks for the different change operations only three different foreground default lists are needed for the QUERY- and ORIGIN-widget (e.g. query widget).

  1. EDB-CHG-QRY-UPP-SLI
  2. EDB-CHG-QRY-BIG-SLI
  3. EDB-CHG-QRY-SLI

The "Query Form Parameter" and the "Origin Form Parameter" inside the Operation Form tab of the configuration are just the names of the lists which will be opened invisibly in the background as virtual widgets. They contain the data that is shown in the visible query and origin widget.

 
Change Operation Foreground Query Widget Foreground Origin Widget
Withdraw EDB-CHG-QRY-UPP-SLI EDB-CHG-OLD-UPP-SLI
Modify EDB-CHG-QRY-BIG-SLI EDB-CHG-OLD-SLI
Replace 1:1 EDB-CHG-QRY-BIG-SLI EDB-CHG-OLD-SLI
Replace 1:n EDB-CHG-QRY-BIG-SLI EDB-CHG-OLD-SLI
Replace n:1 EDB-CHG-QRY-SLI EDB-CHG-OLD-BIG-SLI
Correct EDB-CHG-QRY-BIG-SLI EDB-CHG-OLD-SLI
 

Further entries in the configuration are not anymore as relevant as before. It will work also without any entry in the Operation Form tab and/or Field Assignment tab of the configuration. So the following four cases are possible:

  1. If entries exist in the Operation Form and in the Field Assignment tab of the configuration, they are prior-ranking to the default forms and default fields. The default form is the aggregate or refine list of the underlying relation. The default fields are the significant fields of the corresponding refine and aggregate lists of the underlying relation.

  2. If entries exist in the Operation Form tab but do not exist in the Field Assignment tab of the configuration, the forms are prior-ranking to the default forms, but due to missing entries in the field assignments we use the significant fields of the corresponding refine and aggregate lists of the underlying relation.

  3. If entries do not exist in the Operation Form tab but exist in the Field Assignment tab of the configuration, the default forms of the aggregate and/or refine list of the underlying relation are taken as query and origin widget and the entries of the field assignments tab are taken prior to the default fields.

  4. If no entries in the Operation Form tab and in the Field Assignment tab of the configuration exist, the default forms (aggregate or refine list of the underlying relation) are used. The significant fields of the relation and/or aggregate list are put into the main widget and filter. The dot (.) of the field name is replaced by a hash (#).

 

 

Positioning the Sub-Widgets

  If you have an item-item relation, one item is the so called parent and another one the so called child item. You can view the relation from 2 different sides:

1. The aggregate view: You ask at this view, who is the parent of this relation.
2. The refine view: You ask who is the child of this relation.

DataView has since ever the limitation that you can not combine both views in one form. One of the reasons for the name monster mask and their complex handling is that the mask combines both views. This was only possible by using calculatoric visible masks with a connection to a virtually opened real mask in the background. The query widget and the origin widget are calculatoric widgets which are synchronized during runtime with their virtual widgets in the background. The only 'real' widget is the new widget, which is in edit mode. The calculatoric sub-widgets are:

 

Query Form:

 
Mask Name Operation(s)
EDB-CHG-QRY-BIG-SLI ALL other Operations
EDB-CHG-QRY-UPP-SLI CORRECT-Operation
EDB-CHG-QRY-SLI REPLACE N:1 Operation
  Origin form:
 
Mask Name Operation(s)
EDB-CHG-OLD-BIG-SLI REPLACE N:1 Operation
EDB-CHG-OLD-UPP-SLI CORRECT-Operation
EDB-CHG-OLD-SLI ALL other Operations
  In case you want to position the monster mask sub-widgets you have to open the corresponding calculatoric sub-widget and change its ROW and/or COLUMN value.
   
 

New widget - special handling for entries like *** in fields with a menu

Please use xchg_cch_chk_men instead of cch_chk_men. Xchg_cch_chk_men ignores entries like *** which are used as default entry for unchanged relation fields in the edited new widget of the so-called monster mask!
 

New widget - special handling for entries in the relation fields in the first row

  For all replace operations and the modify operation, the relation fields (visible or invisible) are initially set to the value "***". Without a change, the entries from the parent data set will be used. Existing field defaults will overwrite the "***" value, except the relation field is in the filter and has no query condition (empty). Furthermore, the possible entries of other tables (not the main table and not the join table) are cleaned during specifying the operation.
  In case of re-specifying the operation, additionally the previously changed field values (dirty fields) are also overwriting the"***" values.
 

New widget - special handling for position number fields in the following rows

  In case of a Replace 1:n and a Replace 1:n all operation the value of the position number field is always set to "***" because the real position numbers must be calculated separately for every corresponding parent record.
 

The Location Filter

 

Because the NEW-widget is in edit mode, no other sub-widget of the monster mask can be accessed. To enable the user to query for locations, a modal filter widget is supported. By pressing the “Filter” button the widget is opened. Empty filter fields automatically lead to a "***" value in the corresponding fields of the new widget. The field access of the filter fields can be configured in the change management configuration settings. In the Relation Field Access tab you can set the field access to the following values:

  • r = read only
  • w = writeable
  • f = filter dependent (if a filter criteria is defined, the field is writeable; otherwise it is read only)
  • m = mandatory
 

The Location Filter widget

  The location filter widget is opened by the userexit xchg_sup_qry_wdg which has by default the form EDB-CHG-QRY-CFR as parameter. The userexit to open the location filter is placed inside the no-select menus of the corresponding main forms (see Change Management Configuration->Tab:Main Form Parameter). There are several possibilities to set up the filter form:
  Default:
  By default the location filter form EDB-CHG-QRY-CFR is empty. Just the basic entity T_CENTRAL.COMPARE as kind of dummy entity for calculatoric fields is inside the field assignments. During the opening of the filter form, the field assignments of the corresponding operation are used to fill the form (see Change Management Configuration->Tab:Field Assignment). Such a field assignment maps a calculatoric field with a real existing field. The calculatoric fields are copied into the filter form one above each other. The size of the form increases automatically, if necessary.
 
  The same fields are placed into the main widget of the monster mask (see monster mask picture below).The start location inside the main widget is defined by the row and column of the invisible EDB-CHG-QUERY-DUMMY. The calculatoric fields are necessary because the filter widget fields as well as the fields in the main widget should show the query values which can be combined with logic operators, not the real existing entries.
 
  Customizing:
  Basically, it is possible to customize everything. It is also possible to mix customizing with the automatic generation (see default case), but the customizer should know that the generation algorithm is a simple one. Customizing is always used prior to the default what can quickly lead to conflicts with the automatic generation algorithm. The result may look weird. Therefore, the following is recommended: if you customize, it's better to customize the filter as well as the main widget of the monster mask.
  The following description will show the customizing on the already existing masks and fields. The customizer can always create everything on his/her own and add additional fields and use them instead of the existing ones. Just one thing is absolutely necessary: the fields used in the location filter MUST be visible inside all sub-widgets of the monster mask.
  As an example, the changes for a customized location filter for the Replace 1:1 BOM operation is shown:
 
  1. Create a new field EDB_CLASS_CODE (corresponding to T_GROUP_DAT.CLASS_CODE).
  2. Open System>Change Management>Configuration and search for BOM.
  3. Open the tab Field Assignments and create a new field entry T_GROUP_DAT.CLASS_CODE PARENT EDB_CLASS_CODE.
  4. Open the tab Operation form, select one operation, e.g Replace 1:1, and get the name of the widget from the Main Form Parameter column. For Replace 1:1, it is EDB-CHG-R11-CFR.
  5. Open the EDB-CHG-R11-CFR form and add additional fields as shown below.
  6. Open the EDB-CHG-QRY-CFR form and add additional fields as shown below.
  7. Add the T_GROUP_DAT.CLASS_CODE field to the EDB-ART-STR-ALI form.
 
  The size of the location filter widget is still generated automatically. Also the position of the buttons. The result looks like this:
 
You must not use invisible fields for the field assignments!
  Empty Field Assignments:
  In case even the default entries of the change management configuration are not available, the visible significant fields of the underlying relation are taken as default and will be generated in the location filter. The names for the calculatoric fields are the real field names where the dot (.) is replaced by hash (#).
  Example: T_MASTER_DAT.POS_NO -> T_MASTER_DAT#POS_NO.
  In case of our example it would be the item-item relation and the view STR, so the visible significant fields of EDB-ART-STR-ALI are taken.
 

Using the Location Filter

  The handling for strings with white spaces of the monster mask filter widget corresponds to the standard DataView handling in query mode. String field values with white spaces will be set automatically between apostrophes to avoid error messages due of too many parameters.
  Example:
  This is my string is automatically changed to 'This is my string'.
  In case you add apostrophes by yourself the filter will recognize them and not add them a second time. An exception is if additional logical operators are used (|=OR,&=AND).
  When writing This string | that, the following error message appears:
  Please insert just one search item or connect them with logical operators !
  This error message appears because DataView in this case is not able to decide if 'This string | that' or 'This string' | that is meant.