Performance credit master data (FD32)--SAP Note 705317

Question

Hi,
When running the FD32 tranasaction,I am changing the credit account and saving the transaction...it is taking quite a long time and going for dump....TIME_OUT error.
The appropriate notes for this problem are 705317 and 9937.
I shall give the details details of the note.
SymptomLong runtimes occur for the reorganization of credit data in SD documents.
This reorganization can occur in two situation:
- You start report RFDKLI20.
- You create or change credit master data in Transaction FD32.
Reason and PrerequisitesIn the credit management, you change assignments in Customizing or create or change
credit master data. The transfer of the changed settings into existing SD documents
requires a reorganization of these documents.
The reorganization is triggered from Transaction FD32 or using report RFDKLI20. Since
the relevant partner function in the credit management is the payer, all open sales
documents for a payer are selectedfor the reorganization.
The selection is performed within function module SD_CREDIT_RECREATE, which is called
from both Transaction FD32 and report RFDKLI20.
The documents are selected according to one of the two following options:1. Partner index VAKPA
The relevant documents are selected via partner index VAKPA. In index table VAKPA,
the system updates all SD documents for a customer number in dependency on the
partner function. All documents for a payer can be determined using index table
VAKPA.
CAUTION: Partner index VAKPA is only updated if the corresponding partner
functions and transactions are activated in Customizing table TINPA. Table TINPA
does not provide any update for the payer partnerfunction in the standard system!
2. Document table VBPA
If the update for the payer is not active in table TINPA, the relevant documents
are selected via application table VBPA. Table VBPA contains the used partners
(customer numbers) for SD documents.
The access to table VBPA with the customer number of the payer requires a long
SAP Note Nr. 705317 07.02.2008 Page 1
runtime because the customer number is not a key field in table VBPA. It might
result in a TIME_OUT.
Solution
Due to the technical conditions described above, there are two possible solutions for
runtime problems in Transaction FD32 or with report RFDKLI20:
1. Activate the update of index table VAKPA for the payer partner function:
Activate the update of index table VAKPA for the payer partner function by
creating an entry with transaction = 0, partner function = RG in table TINPA. You
can use Transaction SM31 for that.
Subsequently, a reorganization of index table VAKPA is absolutely required!! You
can execute the reorganization with report RVV05IVB. Note that all existing SD
documents thus also those ones already closed are indexed again by this report.
Depending on the number of your documents in the system, this can result in a
runtime which is correspondingly long. Therefore test this beforehand in a copy of
your production system!
2. Create a database secondary index for table VBPA:
If a reorganization of index table VAKPA is not possible or not wanted, you can
optimize the access via document table VBPA. For that, create a database secondary
index for table VBPA.
We cannot provide a general recommendation on how you have to define the secondary
index in detail. This basically depends on your dataset.
Use the SQL trace with Transaction ST05 in order to analyze the access onto table
VBPA within function module SD_CREDIT_RECREATE. Then define a suitable database
secondary index for table VBPA according to your analysis results.
For example, you could create the secondary index for VBPA fields KUNNR and PARVW.
Test the new secondary index by creating an SQL trace with Transaction ST05 again
in order to check the effectiveness of the database access and the runtime.
Also take the related notes into account.
Use Note 99937 to avoid the automatic reorganization - and thus runtime problems - in
Transaction FD32. Note that this does not solve the runtime problem during the
reorganization in general, but shifts it to RFDKLI20 which you can schedule as a job.
Thus, you are not disturbed by the runtime problem.
Please can anyone help me as to in  which table and what fields i need to take to create secondary index.Thank you,
madhu.

Answer 1

Hi
Instead of creating Indexxes u contact basis to increase the the time limit for the execution
Regards
Shiva