Hierarchy
SAP_APPL (Software Component) Logistics and Accounting⤷
CA-GTF (Application Component) General Application Functions⤷
BAM (Package) Technical Application Analysis
Basic Data
| Data Element | NODE51000 |
| Short Description | Documentation for pricing node |
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 | 10 | 1 |
| Medium | 15 | 1 |
| Long | 20 | 1 |
| Heading | 1 | 1 |
Documentation
Description
These key figures refer to the core areas of Pricing which form part of SAP Sales and Distribution processing.
Pricing can result in a bottleneck situation because it is used frequently in a document. It is normally carried out when creating a new price-relevant item, or when changing item data such as amounts, partners or special fields, which have been defined as price-relevant.
Pricing is implemented using condition technology. The key figures show information from the documents such as pricing-relevant items and also important condition technology elements such as the pricing procedures, condition types, access sequences and condition tables.
As well as the document data and Customizing information, an analysis of the condition types in the table KONV is used as a basis for the key figures. The term "used" always refers to the KONV analysis, i.e. if we refer to the relevant condition type or the elements derived from this such as the access sequence as being "used", it means that they come up in the KONV table.
Objects of the examination are for example:
Condition types, which cause automatic accesses, for determining prices and conditions automatically. This does not apply to condition types, which have been identified in the pricing procedure as "manual" or those which have not been assigned access sequences.
To minimize the number of accesses to condition tables and if possible to buffer these tables, i.e. to move the accesses into the system memory instead of creating database accesses.
When using group conditions, pricing for the relevant condition types is at the end of processing, i.e. before "saving" is carried out again, as it is only here that it is accepted that the document is now fully completed and that there are no further additions to be made.
Implementing a price calculation several times as part of a process chain is not always a good idea, as it can restrict the lead time of a process and so this should always be thought through carefully first.
Example:
Pricing is carried out as part of a quotation, the agreed prices and conditions are valid for both negotiation partners until the end of the quotation. If the customer then implements the quotation and places the order, then all pricing parts should be transferred over unchanged according to the agreement.
By mistake an unlimited "new Pricing" has been set up in the document flow control or the parameters of the standard system have not been questioned or have only partly been taken over.
Moreover a new billing type has been set up and its pricing has been set up in document flow for test purposes for "new Pricing" but due to the fact that one of the employees has been ill, it has not been corrected.
In this example, pricing has been implemented unnecessarily twice too often. Once during order creation and once during invoice creation.
If we first of all pass over the functional inconsistencies, for example, price changes in the time between the quotation and the invoice, we can see that by implementing an additional pricing, the load
on the system is unnecessarily increased at the various stages.
The situation can be tightened by carrying out a comprehensive control of pricing, particularly when the optimization measures below are not used or are incomplete. This enables response times to a transaction to the exact minute.
Pricing is only one of the SAP functions, which uses condition technology. All functions which work in a similar way with procedures, types and sequences should be subjected to an analogue optimization examination. Other SAP applications such as Purchasing or Production use Pricing in Purchase Orders or for calculating production orders.
Focus points
Those parts of the function which need a large amount of resources are examined.
Experience has shown that these are
the number and size of pricing procedures used,
non-used condition types,
frequent use of condition types, which appear as group conditions,
frequent use of condition types, which are important for rebate processing,
frequent use of condition types, which work with the condition update and condition index,
the access sequences and the number of assigned accesses and tables,
and the use of optimization measures in the SAP standard such as
access optimization (Pre-Step), a test access with header fields, to economize, if necessary, on further accesses according to document item,
"Conditions"(User-Exits), which control processing and are assigned at condition type level per procedure,
"Conditions" (User-Exits), which control processing at the level of an access assigned to an access sequence,
exclusive access for each access to an access sequence, which after the first successful access stops further accesses,
and the initial value check at field level within an access, with whose help accesses can be avoided.
Other system parts (e.g. User Exits), which are normally the object of individual procedures and extensions as part of the SAP introduction, are also examined.
References
Please see the relevant publications in SAP TechNet.
History
| Last changed by/on | SAP | 19990223 |
| SAP Release Created in |
