Hierarchy
SAP_APPL (Software Component) Logistics and Accounting⤷
CA-GTF (Application Component) General Application Functions⤷
BAM (Package) Technical Application Analysis
Basic Data
| Data Element | RT_NODE51000 |
| Short Description | Retail: Docu for node 50000 (functions) |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CHAR1 | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 0 | |
| Medium | 0 | |
| Long | 0 | |
| Heading | 0 |
Documentation
Description
These key figures refer to the core Pricing areas within SAP Retail processing.
Pricing can lead to a bottleneck situation, because it occurs within a document. It is normally implemented during creation of a new price relevant item, or when changing item data such as amounts, partners or special fields, that have been defined as price-relevant.
Pricing is carried out using condition technology. The key figures show information, for example, on the number of pricing-related items as well as information on important elements of condition technology such as the pricing procedures, condition types, access sequences and condition tables.
As a basis for the key figures alongside the document data and Customizing information there is an analysis of the condition types in table KONV. The terms "used" or "applied" are always connected with the KONV analysis. This refers to whether the condition type in question or the elements derived from this, such as the access sequence, are 'used', that is to say, whether they occur in the table KONV.
Objects of the evaluation are, for example:
Condition types, that cause automatic accesses to determine prices and conditons automatically. This does not affect those condition types, that are identified in the pricing procedure as "manual", or those that have not been assigned an access sequence.
Minimizing the number of accesses to condition tables and, if possible, buffering these tables, that is to say storing the accesses in a system memory instead of creating database accesses.
When using group conditions, pricing for the condition types concerned is carried out at the end of processing, that is to say before saving, as only then can it be assumed that the document is complete and no more enhancements are to be made.
It is not recommended that you carry out a pricing calculation more than once in a process chain, as this can affect the running time of a process.
The situation can be improved by a comprehensive pricing control, particularly if the optimization measures below have not been used or were not used in their entirety. This can result in a response time for a transaction to the nearest minute.
Pricing is only one of the SAP functions, that has been carried out using condition technology. All functions, which work in a similar way with procedures, types and sequences, should be subjected to an online optimization evaluation. Other SAP applications, for example Purchasing or Production, use pricing in purchase orders or for calculating production orders.
Focus points:
Those parts of the function that may have high resource requirements are evaluated.
Experience has shown that these are
the number and size of pricing procedures used,
those condition types not used,
the frequent use of condition types, that appear as group conditions
the frequent use of condition types, that are important for rebate processing,
the frequent use of condition types,that work with the condition update and condition index,
the access sequences and the number of accesses and tables assigned to them,
and the use of optimization measures in the SAP standard system such as
access optimization (Pre-Step), a test access with header fields, to save on further accesses for each document item,
"Requirements"(User-Exits), which control processing and are assigned at condition type level per procedure,
"Requirements" (User-Exits), which control processing at access level and are assigned in an access sequence,
the exclusive access for each access in an access sequence, which includes further accesses, once one access has been successful,
and the initial value check at field level within an access of an access sequence. This can be used to avoid accesses.
In addition other system parts (for example, user exits) can be included in the evaluation, if these are normally the object of individual procedures and enhancements.
References
See the relevant publications in SAP TechNet.
History
| Last changed by/on | SAP | 19990223 |
| SAP Release Created in |
