Performance of SDBILLDL Jobs in Background - High number of Updates

[former_member240105]

Dear Collegues,

                                We have recently gone live ( ECC 6.0 EHP4 ) and when we run SDBILLDL jobs during night for invoice generation, it generates high number of updates and uses all  available Update processes ( 100 ) across all application servers and  this stops everyone else doing any updates as their updates will go in wait queue. The reason why I am asking is , we have other ERP systems and we don't see this issue there.

Initially we thought it  might be an issue with buffering of object RF_BELEG and did buffered RF_BELEG ( parallel ) but still the issue persissts. How can we control the number of update processes that SAP allocates to this billing jobs?  Since i am from Basis background , I am clueless on this as the trace doesn't show anything suspicious. Has SD functional team has missed out any config or something related to this ? Any input on this is highly appreciated.

Thanks,

Hari- SAP Basis

[former_member131691]

Hi Hari

On the application side when the background job is creating the billing documents there are 3 steps

1) the creation of the billing document

2) the posting of the FI document

3) the generation of the billing output

In cases where you have large volumes of data being processed you should not process all 3 steps

at the same time. Splitting the steps allows you the benefits of parallelisation and in essence reduces

the runtime by 2 thirds.

You can split the steps as folls and then analyse each step in isolation for optimisation opportunities.

Place a posting block on your billing types involved in transaction VOFA this separates the steps one and 2 the FI postings can be scheduled shortly after step 1 with RVFAKSPE

Change the output timing away from immediate this separates the step 3 from step 1 and again the

output  can be scheduled shortly after step 1 with RSNAST00

This should help you overcome your immediate issue and each step can be checked in isolation afterwards. It would be unusual that the billing creation itself would be problematic from a performance point of view, perhaps the longest time consumer there is most likely to be the pricing.

In this regards see note 1738398 which enables the prestep optimiser to reduce the pricing load in your billing creation.

I hope this helps you further

Kind regards

Brian

[Former Member]

Hello,

We are facing a similar issue with SDBILLDL job.

Some days the job gets completed soon and some days it gets delayed.

All days almost similar number of invoices are created.

The creating time of invoices are also similar.

But the completion of jobs gets delayed some days.So I belive the issue would be in posting of FI document or genertion of billing documents.

Could there be some reason why posting or generation of billing documents take more time some days.

Thanks,

Karthik

[eduardo_hinojosa]

Hi

See notes 1852385 and 1830353.

Regards

Eduardo

[former_member240105]

Eduardo - I traced the entire run and I don' see any expensive statement as mentioned in the Note and actual problem here is about the high number of updates being created.

[eduardo_hinojosa]

Hi

Maybe you are generating a huge quantity of invoices. Brian is right. Avoid the creation of FI documents with the proper settings in VOFA and create them after.

You can check also your summarizing FI documents. SAP Note 36353 - AC interface: Summarizing FI documents. If you are creating a lot of items in tables BSID/BSAD this increase the number of updates.

If you are using SIS, avoid the syncronous update. Are you using COPA? Check Note 553626 - FAQ Note Profitability Analysis (CO-PA).

I hope this helps you

Regards

Eduardo

[ivano_raimondi]

Hello,

please check by SE37 if the userexit EXIT_SAPLV60P_009 has been implemented.

Best regards,

Ivano.

[former_member240105]

Hi Evano,

                Yes, I can see the function module EXIT_SAPLV60P_009 in SE37 and it is being used in the below program.

Program                                 Found locations/short description

LV60PU07                            32   CALL CUSTOMER-FUNCTION '009'

                                              TABLES

                                                   CT_VKDFIF = V60P_INPUT_VKDFIF

                                              CHANGING

                                                   CD_MAX_DOCUMENTS = MAX_DOCUMENTS

                                              EXCEPTIONS

                                                   OTHERS     = 1.

Thanks,

Hari

[ivano_raimondi]

Hello Hari,

in the source code of EXIT_SAPLV60P_009 there is the include zxv6pu09.

Please double click on it and check if it exists.

If exists, please copy here the source code implemented there.

Best regards,

Ivano.

[former_member240105]

Hello Ivano,

                   I don't see any code for include zxv6pu09. When I double click, I am getting the below warning.

Program names ZX... are reserved for includes of exit function groups

function exit_saplv60p_009.

*"----------------------------------------------------------------------

*"*"Lokale Schnittstelle:

*"  TABLES

*"      CT_VKDFIF STRUCTURE  VKDFIF

*"  CHANGING

*"     VALUE(CD_MAX_DOCUMENTS) LIKE  SY-TABIX

*"----------------------------------------------------------------------

include zxv6pu09 .

endfunction.

Thanks,

Hari

[Former Member]

Hi Hari,

Could you let me know what is the variant value used for RV60SBAT? There are some critical field that I will be focusing.

1. Under Job Allocation -> Number of Jobs, Cust Per Set, Target Computer

2. Under Update -> Asynchr, Sync via VB log, Sync w/o VB log.

I would first toy around these parameters. Hope to hear more from you.

Thanks

Leonard

[former_member240105]

Hello Leonard,

                      Thanks for checking. I don't see any values defined for Job allocation ( all fields are blank) and for Update Asynchronous option is selected.

Thanks,

Hari

[Former Member]

Hi Hari,

Ok.  Looks like the job setup is fine.  I am not expecting Job allocation to be blank though but probably not the root cause.  I am assuming that you have read the related OSS notes and still no clue on this.  Two approachesI would take.  My preference is actually technical one as that is the most reliable. Nevertheless, you decide.

The technical approach will be do a performance trace using just a selected number of billing docs in background. That should give you clue on what is the abap program doing.  Where is the specific bottleneck?

A more functional approach will be like peeling the onion. I would get my SD consultant to reduce the processing as much as possible. E.g. Disable output from issuing. Disable LIS, Disable Customer Modifications etc.  Basically strip down the potential processing in update task and isolate the feature that is the root cause.  There are situations that you can delay certain processing. You can populate SIS, issue output, trigger idoc in separately with background job that aren't necessary to be synchronously during Billing Creation.

Anyway, please do not hesitate to reply to this thread if you have further questions.  Hope the above helps. I would partner with SD and Dev.

[Lakshmipathi]

Please try with RV60SBAT which is specifically provided by SAP for background job.  The one which you had mentioned is intended for foreground and also not recommended to schedule as a background job.

G. Lakshmipathi

[former_member240105]

Thanks Lakshmi, These jobs (SDBILLDL) are not scheduled manually and gets kicked off automatically with the report RV60SBAT in background.

[Lakshmipathi]

Sorry I am unable to understand what do you mean by :kicked off automatically".  As I already stated, program SDBILLDL will not support background job.  Still if you want to run this in background, you need to do coding corrections as recommended in the following note

• Note 652219 - SDBILLDL cannot be executed in background

G. Lakshmipathi

[former_member240105]

Corrections from Note 652219 seems to be valid only for 46B to 470. Since we are on ECC 6.0 EHP4, it is not applicable for our release.Coming to your point "kicked off automatically". SDBILLDL jobs gets kicked off by RV60SBAT program in schedule in batch. The real problem here is why so many updates are generated by these jobs during their runtime. I searched many Notes and SDN Blogs and none of these seems to be addressing this issue. Also,not sure if any config/user exit causing this.

Thanks,

Hari