Hierarchy
⤷ CA-GTF (Application Component) General Application Functions
⤷ BAM (Package) Technical Application Analysis
Basic Data
Data Element | VBRP00002 |
Short Description | Documentation for key figure VBRP 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
These key figures give an overview of the size relationships of the saved objects.
They can be used to identify extreme or medium features, from which bottleneck potentials and handling requirements can be derived.
The following is an example of this:
Is it normal to have documents with more than 500 items or are they the exception?
Structure and use of detail displays
The detail display basically represents the frequency with which documents within a size class. The size of the classes have been selected using values based on experience.
Example:
Interpretation:
20,000 objects (for example, documents), that have one sub-object (for example, item),
66,000 objects (for example, documents), that have 2 to 5 sub-objects for example, items),
34,000 objects (for example, documents), that contain 6 to 10 sub-objects (for example, items),
etc.
2,000 objects (for example, documents), that contain 200 to 500 sub-objects.
Notes for optimization
Large objects normally (when using the usual detail functions such as Pricing or the Availability Check) require a lot of access and calculation time, much more so than for smaller objects and therefore if they occur too often, they should be carefully observed and optimized.
A comparison of running times between large and small objects does not necessarily lead to a linear increase in runtime, because due to functions such as the group conditions in pricing, all items in a
document in the final analysis must be processed again when being saved.
Object size can be specified by the business process or through the automatic combination of several source documents, for example, in optimization runs such as the delivery due list or the billing due list.
Examples:
Sold-to party orders are transmitted electronically and generally contain 100-130 items. By using the delivery due list run, deliveries can exist with up to 380 items.
Optimization approaches such as splitting very large documents into several smaller ones requires a very exact and comprehensive business and technical evaluation. Particularly if the object size should be established in the business process.
History
Last changed by/on | SAP | 19990223 |
SAP Release Created in |