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

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.

_______________________________________________