Report CONDITION_PRESTEP_ANALYZE

Documentation
Version 1.01

Purpose
The pre-step in condition technique can be used for runtime optimization. This is especially beneficial if
usually more than one line item is created during document processing.
To improve system performance you can configure the system to execute the pre-step for combinations
of condition type and access. If the pre-step is activated the system searches for condition records by
only taking KOMK-fields (corresponding to document header data) into account. This typically happens
when the first line item is created. If this search is unsuccessful then the access is suppressed for all
subsequent line items.
If an access contains only KOMK-fields, then the pre-step is always executed. Thats also the reason why
configuration is only possible for accesses which contain KOMK- and KOMP-fields (usually corresponding
to header and item data).
With the knowledge of the pre-step functionality described above it is obvious that the activation of the
pre-step is most beneficial if the likelihood that no condition record is found by the pre-step is high. It is
expected that this is the case for so-called selective KOMK-fields. One example is provided below.
The greater the average number of items in a document, the more useful pre-step becomes. The less
likely it is that you will find a valid condition record, the more useful it is to use pre-step (see the
following example).
Example:
In pricing, a customer-material discount is used. The condition records existing are based on customer
data from the document header level and material data from the item level. However, this type of
customer-material discount shall be valid only for 2% of the customers. Without pre-step being active
this would mean that the system would needlessly perform a search for each line item created in 98% of
cases. In this example activation of the pre-step would improve system performance.

For large access sequences it might be difficult to configure the pre-step optimization. Thats why the
report provided with this note 1738389 offers some help. Keep in mind the following dependencies:

The pre-step has to be activated per access per condition type

As the condition type is a client dependent, the pre-step settings have to be done client specific
as well although the access sequences are client independent.

This report covers all these aspects and determines a proposal for pre-step configuration.

Selection Screen

Selection:

Usage: Condition Technique Usage (e.g. Afor Pricing)

Application: Condition Technique Application (e.g. Vfor Sales)
Access Sequence: Access sequence to be analyzed

Mode:

Analysis: Analyses entered access sequence and calculates only a proposal for the pre-step
settings
Interactive: In this mode, its possible to create or remove pre-steps settings depending on the
analysis of entered access sequence.

Options:

Analyze Indices: Displays the database index which would be used by the select statement
executed by the pre-step.
Selective fields: Here it can be defined which KOMK-fields shall be considered as being
selective KOMK-fields. The delivered default contains KOMK-fields which correspond to
identifiers and can be modified. If it is for example known that many sales offices (field KOMKVKBUR) are existing and that only for a small subset of the offices condition records are existing,
then VKBUR would be a selective field and it is recommended to add this field to the list.

Result

Buttons:

Set Pre-step: Pressing button Set Prestep, then pre-step will be set for all marked lines.
Remove Pre-step: Pressing this button, then re-step will be removed for all marked lines.
Accept Recommendations: Pressing this button, then re-step will be removed or set depending
on the recommendation (message).
Save: The pre-step settings will finally be written to the database and to a transport request,
when the Save-button is used.

Columns:
First 4 columns: Access Sequence, Access Number, Condition Table Number and Condition Type
Column: Head
This field indicates that this access only uses fields on header level (i.e. KOMK fields or fixed
values). For more details see also below within Case 1.
Column: Pre-step
This field shows whether currently the pre-step is activated (i.e. entry in table T682V exists)
Column: Update
If this field contains Pending, then the customizing setting within this line is not saved. Thus,
its required to press Save-button to save and activate the setting.

Recommendation (Message):
The report provides hints in the following cases:
Case 1: The access is a pure header access (access contains only KOMK-fields) and the pre-step is set. In
this case the pre-step doesnt have to be activated, because the pre-step reading is anyhow performed
independent how the pre-step configuration looks like. Thus the message Prestep not required is
raised.
Case 2: The access is not a pure header access and the pre-step is not active and contains no selective
KOMK-field. In this case the message Prestep could be useful is raised.
Case 3: The access contains at least one selective KOMK-field. In this case the message Prestep is
useful is raised indicating the recommendation to activate the pre-step.
Case 4: No message appears, because pre-step is already set and considered to be useful.
Case 5: Pre-step is set, but the corresponding access was deleted in between. In this case the message
appears, that pre-step is obsolete and should be deleted.
Case 6: Field for the column Update contains the text Pending. In this case, pre-step was set or
removed and needs to be saved to the database by pressing the Save-button.