Hierarchy

⤷

⤷

Basic Data
Data Element | LIPS00002 |
Short Description | Documentation for key figure LIPS 00002 |
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
Use of the key figure for analysis purposes
The key figures should give the observer an overview of the size relationship of saved objects.
With your help, average and extreme features should be recognized so that bottleneck potential and business requirements can be set up.
The following is an example question:
Are documents with more than 500 items an exception to the rule?
Structure and use of detail displays
The detail display here essentiallly represents the frequency with which documents appear in a size category. The size categories have been chosen using values based on experience.
Example:
Interpretation:
20,000 objects (e.g. documents), that contain 1 subobject (e.g. item),
66,000 objects (e.g. documents), that contain 2 to 5 subobjects (e.g. items),
34,000 objects (e.g. documents), that contain 6 to 10 subobjects (e.g. items),
etc.
2,000 objects (e.g. documents), that contain 200 to 500 subobjects (e.g. items).
Notes for optimization
When used for the usual detail functions such as pricing or availability checks, large objects generally require a great deal more access and calculation time than smaller objects. Therefore if they occur quite often they should be observed carefully and should be optimized.
A comparison of the running times of small and large objects does not necessarily show a linear growth in running time, since with functions such as group conditions in pricing, all items in a document must be
processed again when they are saved in the final analysis.
The size of objects can either be determined by the business process or by the automatic combination of several source documents, for example in optimization processes such as those which influence the delivery due list or the billing due list.
Examples:
The sold-to party orders are electronically transferred and contain as a rule 100-130 items. Due to the use of the delivery due list run, deliveries exist with up to 380 items.
Optimization measures such as dividing up large documents in several smaller ones require exact and comprehensive business and technical consideration. This is particularly sp if the object size is the basis for the business process.
History
Last changed by/on | SAP | 19990223 |
SAP Release Created in |