(DV-2308) SAP Report Comparison with Value Conversion

The report comparison in the SNP Validate supports also the conversion of values in the report output. The whole process is based on parsing the report out to the internal format of a table (or more tables). Then converting values in those tables based on conversion rules. Followed by aggregation of values grouped by FIELD_ID in the configuration mask. Finally, compare the results of the before and after images tables in the table format.

Supported SAP reports

The SNP Validate contains configurations for parsing the following SAP reports:

RABEST_ALV01	Asset Balances
RAGITT_ALV01	Asset History Sheet
RFAUDI04	Number of Asset Master Records
RFAUDI05	Number of Material Master Records
RFDSLD00	Customer Balances in Local Currency
RFITEMAP	Vendor Line Item Display
RFITEMAR	Customer Line Item Display
RFKSLD00	Vendor Balances in Local Currency
RFSOPO00	General Ledger Line Items
RFSSLD00	G/L Account Balances
RIMPOS00	Maintenance Item List
RKKBALV1	Order Selection
RKKBSELL	Sales Order Selection
RM06EW00	Purchasing Documents per Supplying Plant
RM07KO01	Stock Consistency Check
RM07KO01_ALV	Report RM07KO01_ALV
RM07MBST	List of Stock Values: Balances
RM07MMFI	MM/FI balance comparison
RM07MSAL	List of GR/IR Balances

The following SAP transactions are also included as customizing templates (the corresponding customizing has to be copied under the real report name which is unique/generated on each system):

S_ALR_87012993	Orders: Actual/plan/variance
S_ALR_87013542	Actual/Comm/Total/Plan in COAr crcy
S_ALR_87013611	Cost Centers: Actual/Plan/Variance

Prerequisites

Transport with Addon: Layouts for SAP reports has to be imported into the source/target systems. The transport contains a predefined layout /SNP_TBONE for output list formatting.

Create an SAP Report variant with the desired selection and will be set for using this layout.

Variant Setup

To enable the conversion option choose Report Comparison Type Hierarchical Report Comparator in the corresponding Validate’s variant. Choose the profile SNP (or name of own profile which contains configuration for parsing the report output).

Conversion Setup

The setup and the process of conversion of the virtual table (created by parsing report output) are the same as in the table testing.

The Set Conversion rules functionality provides you with two types of rules:

ABAP rule
Value mapping

It is possible to use both options within the same variant, but only one rule can be defined per FIELD_ID in the virtual table.

ABAP rule

It allows the runtime execution of a piece of ABAP code which enables users to create their own conversion of a field value. This is an advanced feature; it is expected that the user has at least basic knowledge of the ABAP syntax and coding.

In the case of rules where data is selected from the database, caution is advised. The code is executed for every line of the data image. Therefore, all accesses to the DB should be optimized. It is recommended to use STATIC local variables to store this kind of content. Using this approach, the data only needs to be selected once and will be reused in every following line evaluation.

To create an ABAP rule, click on the insert row button.

First, fill in the Field name desired FILD_ID from the virtual table (specifies to which column, the rule should be applied), then fill in the Rule Type A (ABAP rule) and the rule name. The ABAP rule name is restricted to a Z prefix for those created by the customer.

The ABAP code of an ABAP rule can be opened by double-clicking on its name. If the ABAP rule doesn't exist, a pop-up will ask for confirmation to create it. Each field of a table can have a maximum of one ABAP Conversion Rule defined in a Variant.

The ABAP editor is opened, which allows the edition of the code.

The code's syntax can be checked with the Check syntax button.

The code can be pretty-printed by clicking on the Pretty Print button.

By clicking on the Confirm button, the code will be saved regardless of the validity of its syntax to allow for continuous writing of the ABAP.

By clicking on the Cancel button, all the changes made to the code from the last confirmation will be discarded. A Variant can be saved with a syntactically incorrect ABAP rule, at saving a warning pop-up will inform the user of the code's incorrectness.

The code of the ABAP rule is locked. Only a part of the form is editable, where the ABAP conversion rule code should be written. The user can access the context information of the processed cell importing from the interface of the form like Run ID, Test plan technical name, Test case technical name, Image type, Variant ID, Table name, Field name as FIeld ID, ABAP Rule name, the original table line, converted table line. The changing parameter cv_value should be set as a response.

Value mapping

It gives the ability to apply simple mapping within the comparison task.

No logic is required, only a list of old and new values corresponding to one another needs to be provided.

To create a value mapping rule, click on the insert row button.

First, fill in the field name (specifies to which column value mapping should be applied), then fill in the rule type V (value mapping rule) and then the rule name. The rule name is restricted to a Z prefix for those created by the customer.

The mapping can be opened by double-clicking on the rule name. Column Old value specifies the value to be replaced. Column New value represents the value to which the corresponding old value changes.

Parser configuration

The parsing process is based on a configuration done for each report, to find all the information displayed in the spool file. This is made by using regular expressions syntax to find the different patterns and other properties can be set to determine the tool’s behavior for certain situations. Values with duplicate keys are merged into one and their numerically defined values are aggregated.

The configuration is built by accessing transaction /DVD/VL_RE_H_CONF - Val.Rep.Test: Hier.Parser Config.

Profiles:

The user can define his/her own profile. The user should not modify the SNP Profile to avoid an overwrite of the modification when installing a new product release.

Report header

Levels (line types) Definition:

Fields definition by level:

Configuration explanation:

Field	Description
PROFILE	SNP delivers a standard profile of report configurations. The users can create their own. SNP profiles should not be modified, to avoid overwriting of custom modifications when a new software release is installed.

Field	Description
REPORT_NAME	If the report is run with /SNP/CN01_CL_TEX_JOB or /SNP/CN02_CL_TEX_REPORT, we have to provide the report name, in case the report is run by the parametric Transaction wrapping program /SNP/CW02_VR_PARAMETRIC_TRX, the name of the transaction must be provided. These SAP parametric transactions have dynamically generated program names, that’s why we need to provide the transaction name instead.

Field	Description
LEVEL_INDEX	This is the key to the level (or line type) definition. It has to be unique, and it is mandatory to set this value as the levels appear in the spool. The tool will follow its sorting to recognize every single line of the report by checking its regex.
LEVEL	Level number. E.g.: 1, 2, 3, n. This value will set how the tree is going to be built. There can be many levels with the same number, but for instance, those levels could have different fields or a different structure. Example: Header information: LEVEL_INDEX 1 LEVEL 1 Detail information: LEVEL_INDEX 2 LEVEL 2 Totals information: LEVEL_INDEX 3 LEVEL 2
REGEX	Regular expression to find the line’s text patterns to determine spool line level (or line type). Many equal regexes can be defined if needed. The tool will check them sequentially as they appear in the table (ordered by LEVEL_INDEX) to both recognize and apply the correct configuration/behavior to the line.
CAPTION_MASK	This parameter sets the caption (key) of each matched node. It can be configured with a text + %<FIELD_ID>; e.g.: Company Code %BUKRS
DO_SUM	This parameter is the input to determine if the level of data needs to be taken into account for aggregate porpoises. It only affects the Conflict Ticket to show the summarized values and differences of the numeric fields of the level.
SPLIT_AT	This parameter can be set instead of using offsets (for each level’s fields) since some reports can be dynamic and have a character in between the fields. If this parameter is set, there is no need to declare the offsets for each field at the fields segment. Example: \| (Several reports have a \| between the columns).
DO_AGGREGATION	This parameter activates the logic to aggregate type N fields and concatenate character field values when duplicate key nodes are present. It merges all the nodes with the same caption that are at the same level. It is always recommended to set it as activated when the caption holds a field with a possible mapping because its value could change and could lead to a duplicate node.
UPPERCASE (obsolete)	It works in conjunction with the CAPTION_OFFSET and CAPTION_LENGTH. When defining a caption by offset and length, if there are differences in some words because of a capital letter in one of the spools, use this flag to make the whole caption set with capital letters. Since release 2022.07 this field is no longer available. Instead, this attribute has been moved to the field level.

Field	Description
FIELD_INDEX	Sequential number to represent the field. As the LEVEL_INDEX, once the configuration is done, the first field has to be the number 1, and the second, the number 2, and so on.
NAME	Attribute name. This is the name of the attribute and its configuration is mandatory. The name has to be unique for the line type.
OFFSET	Where the column starts in the spool file. If property SPLIT_AT is maintained, there is no need to fill this field because its configuration has no effect.
TYPE	C (Character) or N (Numeric). If it is numeric and at level definition the field DO_SUM=X, will be considered to be part of the conflict tickets creation in the summarized and differences data sections.
FIELD_ID	This is the fieldname in the virtual table. This value has to be unique in the whole report definition. A field can be referenced by a numeric field to set the unit of measure or in a Dynamic query of an artificially created field.
NUM_REF_FIELD	If the field type is N, this field becomes obligatory. Indicates what field (referenced by FIELD_ID) is the unit of measure or currency. This field can handle constants between single quotes, for instance, 'Corporate Currency'. Use a constant when there is no way of having the quantity UoM or a currency, or there is no way of having an artificially created field by the developer with a DYN_QUERY to bring, for instance, the currency of a company code that is present in the report.
RELEVANCE	This field is to set 1 or 0 for the relevance of comparison. 1 compare; 0 not compare
DYN_QUERY	This field accepts an OpenSQL statement for getting an extra field that is not in spool which can be configured with the SQL statement and indicate the %number of fields. e.g.: SELECT WAERS FROM TKA01 WHERE KOKRS = '%KOKRS' %KOKRS is the FIELD_ID of a field that contains the KOKRS value.
MAP_MODE	Strict: This option will trigger the precise mapping method. If there is more than one mapping dependent value, the attribute needs to be declared in the view of the dependent fields; otherwise, a message will be raised in the field MAPPING_ERROR (at comparison detailed report) stating there is an ambiguity. E.g.: a report line that has two plants and a storage location. In that case, the solution is to set it as strict and declare the corresponding plant at the mapping’s dependent field view. Soft: This method, after trying the precise (or exact) approach, if there is no match, also checks if the value can be mapped by filtering records of the mapping table, taking out the records that do not match any of its dependent values. In most cases, this is the recommended method.
DOMAIN	This field has two functions. Mappings functionality: it is used along with the TC Scenario set in MC, to search for suitable mappings. Conversion routines: It is used to find the corresponding conversion routine.
CONV_TO_INTERNAL	Activates the conversion routine process. Options: · Do not convert (default) · Convert in the central system (using a generic conversion routine) · Convert in satellite system (using specific conversion routine. The typical case of use would be MATNR) If the operation of one of these two functionalities is requested, the domain must be configured beyond the use of the generic conversion routine because the tool needs to know the length of the field to convert which is derived from the domain.
UPPERCASE	Setting this field will convert the attribute value to uppercase. This is handy when there are capital letters differences between different SAP versions.

If the report to parse has more than one line with the same REGEX, and the developer wants to identify each one. More than one record for this type of line must be declared.