Transaction processing in sales and distribution (SD) generates large volumes of data that in turn automatically update database tables in the SAP ERP system, thereby making the tables too large after a period of productive use. It is important that the growth of SD tables is well controlled to prevent performance impairments associated with large data volume, such as system slowness, prolonged response time, background job termination, or system downtime.

The techniques I’ll discuss apply to all versions of SAP systems. I discuss clear-cut tips and tricks that can aid in the effective management of the database table growth as it relates to transaction processing in the following SD processes, which I chose because of the volume of data they generate:

• Rebate processing
• Sales document flow

• Collective processing run

Rebate Processing

Rebate processing SD allows you to give a discount to a customer based on a defined sales volume. One table that is susceptible to high data growth as it relates to rebate processing is table VBOX (SD Document: Billing Document: Rebate Index). Uncontrolled growth of this table can lead to performance degradation (e.g., slow response and system slowdown) of rebate processing functions such as billing update and rebate index recompilation. Elements such as document types, sales organizations, and customers can be defined as relevant for rebate processing, and these definitions influence how a rebate is calculated. For example, if you define that a particular billing document (such as an invoice or down payment request) is relevant for rebate processing, the system uses the value on the billing documents to adjust the sales revenue accruable to the customer. Therefore, the sales revenue is used in the calculation of the rebate for the customer.

Document items that may be relevant for a rebate condition are determined with the VBOX table. Table VBOX is updated when a billing document is released to accounting regardless of the existence of rebate conditions for the document item. This is because the SAP system supports retroactive rebate processing, which allows you to create rebate agreements for which the validity start date lies in the past.

A good data prevention strategy to control the number of entries in table VBOX is to appropriately configure the setting for the relevance of volume-based rebates for document types, sales organizations, and customers. When rebate processing is not needed, this functionality should not be activated. To activate or deactivate rebate processing, use transaction OVB0 (Billing Documents Types Overview) and check or uncheck the boxes in the Relevant for rebate column (Figure 1). 

Figure 1

Activation or deactivation of document types for rebate processing using transaction OVB0

You can also use transaction VOFA to activate or deactivate rebate processing for billing documents after you select a specific billing document type by clicking the Rel. for rebate check box (Figure 2).

Figure 2

Activation or deactivation of billing documents type for rebate processing

To activate or deactivate rebate processing for sales organizations, use transaction OVB1 (Sales Organization-Rebate) and check or uncheck the Rebate proc. active box (Figure 3).

Figure 3

Activation or deactivation of sales organizations for rebate processing

To activate or deactivate rebate processing for a customer, use transaction XD02. Check or uncheck the Rebate box in the sales area data under the Billing Documents tab of the customer master record (Figure 4).

Figure 4

Activation or deactivation of customer for rebate processing

One of the pricing elements that influences rebate processing is the access sequence. The access sequence defines the order in which the system searches for condition records. You can maintain the access sequence by following IMG menu path Sales and Distribution > Billing > Rebate Processing > Condition Technique for Rebate Processing > Maintain Access Sequences (Figure 5).

Figure 5

Setup of access sequence in customizing with access category options (1 or blank) as inset

The value of 1 in the Ty. (type) column in Figure 5 signifies rebate-based pricing procedures and distinguishes them from standard pricing procedures. To reduce the number of records updated in table VBOX, do not assign access sequences to a rebate condition type if they are not needed. You can control access sequence assignment by using transaction V/06 (Conditions: Condition Types) (Figure 6). This screen shows the assignment of an access sequence (e.g., BO03) to a condition type (BO03).

Figure 6

Controlling access sequence assignment to condition types

Furthermore, you can use the archiving object SD_VBRK to archive table VBOX to reduce data volume. You can also use SD_VBRK to archive other tables that are related to billing documents such as VBFA (sales document flow), VBPA (sales document partner), VBRK (billing document: header data), and VBRP (billing document: item data), which you can access via transaction DB15 (Tables and Archiving Objects) (Figure 7).

Figure 7

Table and archiving objects analysis for archiving object SD_VBRK

It is important that you archive deliveries before billing documents because of the sequence specified in the document flow and information interdependencies within the SAP system. Before a billing document is archived, the system automatically checks if the residence time defined in customization has been exceeded. The residence time defines the period of time that must be exceeded before the system can archive application data. The system also checks if a subsequent document has an overall status of completed if the billing document has a subsequent document (for example, a credit memo request with reference to a billing document).

Sales Document Flow

A sales document is a business database document that is used for processing transactions in the sales department of an organization, such as a quotation or a sales order. The SAP system supports document copy and linking to map business processes appropriately by creating sales documents with reference to the originating documents. Data is therefore transferred from the originating document to subsequent documents while also allowing for a status update on the originating sales document. When creating a sales document based on another sales document, you need to distinguish between source document types and target document types. The source sales document type is the document that you want to copy into another sales document. The target sales document type is the document into which you want to copy another sales document. For example, if a delivery document type is created based on a sales order document type, then the sales order is the source document and the delivery is the target document.

The links between a base document and a target document in a sales process are stored in table VBFA (Sales Document Flow). While it is good to tie sales documents together, it can lead to a high growth rate of table VBFA if not properly controlled. This phenomenon can represent a performance bottleneck, especially during transaction processing when a base document is referenced by many target documents. To control the growth of this table, consider reviewing the copy control function for sales document via transaction VTAA (Order to Order Copying Control). You can deactivate the update of document flow records when you create a target document (e.g., a sales order) from a source document (e.g., a quotation) via transaction VTAA by unchecking the Update document flow check box (Figure 8).   

Figure 8

Document flow control with update document flow indicator options as inset

The document flow record provides information about the quantities and values that are copied from source documents to target documents. The valid options for the updated document flow indicator are:

• Blank – Document flow records are not created
• X – Document flow records are created from the target sales document item to the source sales document item and possibly to other document items referenced by the source document. This option also supports the creation of document flow records from subsequent document items to the source document item and its preceding document items. (Note: Subsequent document items are document items with reference to target document items while preceding document items are document items referenced by the source document item.)
• 2 – Document flow records are created for all sales documents (with the exception of delivery, goods issue, and billing documents) from the target sales document item to the source document item and possibly to its preceding sales document items. Furthermore, document flow records are created from subsequent document items to the source document item and its preceding document items (provided the subsequent document is a sales document). It is important to know that document flow records are not created from a subsequent document item to a source document item and its preceding document items if the subsequent document is a delivery, goods issue, or a billing document.

Program SDVBFA21 allows you to delete superfluous or redundant document flow records for deliveries, goods issues, and billing documents created by the system from table VBFA when the update document flow indicator is changed from X to 2 (Figure 9). As seen in the inset of Figure 9, the program allows you to perform the delete operation for all sales document types (e.g., A for inquiry, B for quotation), a specific sales document number, or a range of sales document numbers (in the Sales document no. field).

Figure 9

Initial screen to delete redundant document flow record after changing copy control

You can perform a productive run of the delete operation by entering X in the Perform update field. Otherwise, a simulation run is automatically performed. Furthermore, the logging of the delete operation (productive or simulation) is supported by entering X in the Issue log field. You should run the program for small document number ranges or use varying criteria to avoid degrading system performance, especially when a large volume of data is involved.

To reduce data volume and enhance system performance, you can use transaction DB15 to archive the content of table VBFA using different archiving objects, such as SD_VBAK (sales documents), SD_VBKA (contacts), RV_LIKP (inbound and outbound deliveries) and SD_VBRK (billing documents), as shown in Figure 10.

Figure 10

Archiving objects for archiving table VBFA

Collective Processing Run

To reduce the number of documents in the system, your SAP system allows you to create different documents for collective processing. For example, you can collectively process sales orders that are due for outbound delivery in a single step, thereby forcing the system to combine the items in the defined sales orders to minimize the number of outbound deliveries. You can do this by following menu path Logistics > Sales and Distribution > Shipping and Transportation > Outbound Delivery > Create > Collective Processing of Documents Due for Delivery > Sales Orders (Figure 11). You can execute the collective processing of documents manually or automatically (in background mode) by choosing the appropriate menu option via the path Program > Execute or Program > Execute in Background, respectively (Figure 11). The number of documents involved can influence how you run collective processing — to avoid performance issues such as slowness and timeouts, the background mode is recommended.

Figure 11

Execution of a collective processing run for sales orders

Table VBFS (Error log for collective processing) acts as a repository for collective processing logs. Over time, this table can grow to the extent that system performance is hampered. Collective processing exists for different processes such as delivery, billing, picking, and goods issue. However, the high growth rate of table VBFS is more associated with collective delivery processing and collective billing processing because other processes generate less data when compared to delivery and billing processes.

You can use program SDSAMPRO (Log of Collective Run) to display the log entries generated by different collective processing upon the definition of an appropriate group type, such as L for deliveries and F for billing documents (Figure 12). The description list is displayed when you click in the Type of coll. run field.

Figure 12

Initial screen for displaying log of collective processing run with the group types as inset

Use transaction SE38 or SA38 to execute program SDSAMPRO to display the report (Figure 13).

Figure 13

Log of collective delivery processing run

You can also display log entries generated by a collective processing run via transactions V_SA (Log of collective run) and V.21 (Log of collective run). These transactions display logs based on defined selection criteria.  

Preventing data updates by adopting message exclusion strategy is key to controlling the growth rate of table VBFS. The inclusion of messages in the collective processing log — especially for delivery — is dependent on the message type. You can define the message types for the system messages of a collective delivery processing run by following IMG menu path Logistics Execution > Shipping > System Modifications > Specify Characteristics for system messages > Define the message types of system messages (Figure 14).  

Figure 14

Define message types for system messages in customizing with valid message types as inset

The following are the attributes of the different message types shown in the inset in Figure 14:

• Blank – No message is generated
• I – Messages appear in the collective processing log if additional customizing settings have been performed via transaction OVM2 (Copy message with type “I” into collective processing log). Messages also appear in a dialog box as information.
• W – Messages do not appear in the log but appear in a dialog box as a warning
• E – Messages appear in the log and in a dialog box as an error

The check box under the Displ.info column in Figure 15 determines whether or not to display information messages in addition to error messages in the log for processes running in the background, such as delivery due list processing in transaction VL04. You should use the message type attributes to restrict the recording of collective processing logs. This can help control the unnecessary growth of table VBFS.

Figure 15

Activation or deactivation of message type I for collective delivery processing log

Another technique to enhance system performance is to delete unwanted logs of collective processing runs. You can delete obsolete collective processing logs via program RVVBSKDL (Delete groups and logs) (Figure 16).

Figure 16

Initial screen for the deletion of obsolete collective processing run logs — program RVVBSKDL

When deleting collective processing logs via program RVVBSKDL, you have these options:

• Delete the log entries, including the group header after the related documents have been archived
• Delete only the logs, in which case the group headers and items remain in the system
• Simulate the delete operation

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.