SAP R/3 форум ABAP консультантов

[admin]

Note 178328 - Problems due to incorrect user exits in SD

Symptom

• When you save changed or new SD documents (sales orders, deliveries, billing documents), massive performance problems occur (delete processes with long runtimes, deadlocks) which may even cause a system crash.
  In modified systems, these problems may occur after the reorganization of the SD indexes using standard report RVV05IVB.
  
• Inconsistencies occur in the worklists of Sales and Distribution (shipping due date index, billing index, transportation planning index).
  
• Change documents are updated incorrectly or not at all.
  
• The statistics of sales order, delivery or billing document are incorrect.

Other terms
VA02, VL01, VL04, VL10, VL01N, VF04, SAPMV50S, SAPMV60S, RV50SBT1, delivery due list, billing due list, material index, partner index, VEPVG, VKDFS, VTRDI, VRSLI, VAKGU, VAKPA, VAPMA, VLPKM, VLKPA, VLPMA, VRKPA

Reason and Prerequisites

You use the user exits in sales order, delivery or billing document processing and access the internal standard table with the document data to change them (you use INSERT, APPEND, MODIFY or DELETE statements).

If the update flag is used incorrectly or if internal tables are filled incorrectly, the specified symptoms may occur without inconsistencies becoming visible in the documents themselves.

The performance problems occur in the update of the SD index tables (shipping due date index, billing index, material index and partner index...).The update logic depends on a consistent status of the transferred internal tables. In case of inconsistencies, a repair mechanism makes sure that no inconsistencies are updated on the database in general.For this, however, runtime-intensive database commands have to be executed which may lead to massive performance problems.

The errors in the user exits may only become recognizable after the reorganization of the SD indexes with standard report RVV05IVB.The report sets up the indexes based on the data available on the database, but the user exits in the sales order, delivery or billing document are not processed.From the viewpoint of the R/3 standard system, the indexes are correct then, but they may be incompatible with the index entries which are created during normal document processing and which are influenced by the inconsistencies in the internal tables.During the update of the SD documents, problems may occur if existing index entries have to be reduced or modified. In this case, however, the problems are caused by the errors in the user exits and not by report RVV05IVB!In the unmodified standard system, no restrictions exist concerning the use of this report.

Solution
In the SD programs, much document data is managed in internal tables starting with letter X or Y (for example, XVBAP, XVBPA, XVBKD, XLIPS, XVBUP,...). If these tables are changed within user exits, it is important that the changes are compatible with the SAP standard logic for these tables.Thus, below you find some general points you have to consider during the processing of the tables within user exits.

• If the specified problems occur, check your user exits concerning these points.
  
• If required, use report RVV05IVB available in your system to correct the SD document indexes (see Note 128947) after you have made sure that your modifications correspond to the SAP standard logic.
  

Note that despite the recommendations below, only the customer is responsible for self-developed modifications in user exits.Problems caused by incorrect source code in user exits cannot be processed within the free of charge R/3 support.

Basic information concerning the management of internal tables in Sales and Distribution

In principle, the administration of X and Y tables in the order, the delivery and the billing document follows a fixed logic.In the following, this logic is described for the case of a closed document processing as it occurs approximately immediately before the saving of the document (for example in user exit USEREXIT_SAVE_DOCUMENT_PREPARE).In the user exits which are called during the document processing, there can be temporary deviations from this logic which cannot be handled here.

• The X tables contain the current status of the document including the changes applied in the current transaction.
  
• The Y tables only play a role in the change mode of document processing. They contain the original status of those table entries changed during the current transaction.Thus the entries in the Y tables reflect the previous status of the document on the database.
  

Via the update indicator of the individual table entries in the X and Y tables (field name UPDKZ) you can control whether an entry was added (update indicator I), changed (U) or deleted (D) or whether it was not influenced at all (the update indicator is initial).

In general, the following context exists between the update indicator and the Y tables:

• When you create a document, only update indicator 'I' can occur in the X tables (or sometimes it remains initial). No records exist in the Y tables.
  
  
• When you change a document, the following cases may occur:
  - You add a table entry.In the X table, only one entry with update indicator 'I' exists.In the Y table, no entry exists.
  - You change a table entry. The X table contains the changed entry with update indicator 'U'. The Y table contains the original table entry with the status as it was before the change, and the update indicator is initial in general.The Y table may only contain one entry with the same key in each case.
  - You delete a table entry. In this case, the X table contains this entry with update indicator 'D'; the entry can also be deleted from the table directly (for example, from table XVBUP).The original entry (status before the deletion) is contained in the Y table and has also update indicator 'D'.
  
  
• The X tables may contain any number of entries with the same key and update indicator 'D', but only a total of one entry with update indicator 'I' or 'U'. If you want to execute a targeted access to a certain table entry within a user exit, the system should always query the update indicator as well so that it only takes active entries into account.
  When you display documents, update indicator and Y tables are irrelevant.
  

The attached correction instruction (object ZUSEREXIT1) describes by means of the example of the table with sales order item data (XVBAP) which logic the change of existing entries in this table must follow.You could implement a similar logic in a user exit within sales order processing.
The second object ZUSEREXIT2 describes by means of the example of the partner table (XVBPA) how you can apply a new entry which is compatible with the SAP standard logic.

General recommendations for the use of user exists (Include technique)

• Current header lines of internal structures or current table structures should not be changed within user exits because this often causes errors.If possible, use local structures for the data transfer from and to the internal table.
  
• You should not delete entries from the standard table or provide them with update indicator 'D'. Inconsistencies could occur with respect to dependent entries in other tables.In addition to the above symptoms, for example, requirement errors could occur.
  
• When you change individual fields in an internal table (for example, XLIPS, XLIKP), make sure that the line which fits the work area of thetable is changed (for example, MODIFY XLIKP INDEX 1 generally causesinconsistencies or terminations).
  
• You should not change the sorting of the internal standard tables because this can cause problems during the access to these tables. Many tables are sorted by certain key fields so that they can be accessed effectively with binary search. If you want to sort the table differently, use a copy of the standard table.
  

If you have further questions, contact your SAP consultant or the Remote Consulting Service.

Related Notes
841758 - Procedure when you experience performance problems
757361 - Additional data records in BW when document changed
415716 - User exits in delivery processing
356061 - Incorrect index compilation caused by own checks
301254 - Creation of billing index
128947 - Correction of SD document indexes with RVV05IVB