returns lot - performance issues

[prasadssvga]

Is there a way to run parallel processes or mass processing for FPB5? Is it mandatory to have only one FI RECON key per company code/vendor?

Process:

We have 6 files each per company code and vendor combination. From each file, records for NOC(98) and returns(99) are separated and new files for NOC & RETURNS are created again. While the new files are written to application server, recon keys are generated in programmatic way, per company code & vendor combination. These files are submitted to FPB5 for processing returns. Each job runs for 2 hours approximately.

[AmlanBanerjee]

Hi Prasad,

It is not mandatory to have one recon. key for a combination of Company Code and House Bank (Vendor). However, just check with your Finance Reconciliation team whether they are using this reconciliation key for their day to day reconciliation purpose or not.

Spliting one Return file into multiple Return lots and processing them in parallel is possible and will definately reduce time. However, you need to optimize the number of entries that you want to process in one Return lot.

So from the process that you have mentioned, you have 6 return intermediate files that gets created and they are assigned 6 reconciliation keys and are submitted to the report RFKKRL00.

I guess you are using a custom program to separate the NOC and the return line items.

In there add a piece of code, for each of the return file,take the total number of return records in an internal table from the initial Return file and based on the number of records that you ant to process in a lot (say 2000) , refromat the data taking the 2000 records and prepare the intermediate file and call the standard program RFKKRL00.

Subtract 2000 from the total number of records in the internal table and repeat the process until the total number of records in the internal table is 0.

So in this for each of the intermediate file, there will be a separate return lot number and the separate reconciliation key.

And for processing the Return lots is parallel,  you can use the FM FKK_REFUSAL_LOT_TRANSF_START.    

Make sure that you are giving a delay b/w the passing of the intermediate files into the program RFKKRL00

Also, when you are creating new jobs for processing them, make sure the background processes in the system are free to be used up, other wise these jobs will go into "released" state and will not get process parallely.

Hope it helps...

Thanks,

Amlan

[prasadssvga]

Thank you Amlan,

I understand your point. All this sounds good.

I looked into the files that are generated, each file has record count b/w 40 to 100. Currently all 3 files are submitted in parallel using RFKKRL00 as background job. So I am totally clueless about this large processing time.

Any clues? Does this has any relation to cash management? I see there is check for parallel update to CASH Management in SPRO->FICA->Technical Settings for mass jobs

[AmlanBanerjee]

Hi Prasad,

That's sound really wierd ...Processing of a return lot containing 100 records should not take more than 5-10mins (max) in an ideal scenario.

If we ignore Cash Mgmt part for a moment, and concentrate on finding the root cause in core ISU return process, then you can check the following-

(a) Any exhaustive query getting executed in any one of the return events,The main events that you can check are 253,255,256,295 and 299.

(b) Any implicit enhancement under the include programs in RFKKRL00, that is increasing the processing time

(c) Proper indexing for the return tables,FKKRLST,DFKKRK, DFKKRP,DFKKRH etc.

You can put a trace on while processing the return lot and you will be able to find out the database tables, that have a high response time.

Now with Cash Mgmt,I guess you have configured the other processes as well, like the payment lot etc. So now,are you experiencing high processing time for payments as well?

I don't think activiating the parallel update for CM for 100 records will cause high processing times.

As a last option, you can raise an OSS with SAP to investigate the same.

Thanks,

Amlan

[prasadssvga]

Yes, all other processes too take lot of time. Our client has average of 80,000 invoices per day and the batch process starts at 4:30 PM and goes up to 8 AM next day. This run time is excluding BW jobs which start at 6 AM in parallel.

Thank you very much for these pointers. I will check with application support team on enhancements.