Long Pending Jobs

[Former Member]

Current Business Process :

Unilever has got one contract per concessionaire (about 125 in total) and 450.000 cabinets approximately. Due to this amount of items there are lot movements along the year, assignments, transfers, lostu2026 All of them are managed by deliveries document, and most of them require an update of the concessionaire contract (in order to add the cabinet, delete or just maintain them).

Since the number of items and the deliveries are so many, the process of contract maintenance would be impossible to be done manually; and this is why a custom program has been developed.

Although there will be the possibility to execute the program manually, it is usually run daily through the YCAB_PROCESS_CONTRATTI job. The job run a custom program that collects those deliveries that are relevant for the Cabinet process (Z2_CABMSG2). Once done, it creates a new job with these deliveries as selection parameters of the custom program Z253408_CONTRACT.

The program Z253408_CONTRACT retrieves all data from the deliveries, creates a batch input session and updates the contract trough a call of the standard transaction VA42.

Problem:

We have a scenario last 2010 campaign year where the delivery is not processed by the Job on or before September 30, 2010. Since this is a long running, the said delivery where processed on campaign year 2011 u2013 around October 2010. With this, calculated dates are incorrectly determined. This scenario only shows that Long running Jobs for this process also impact on the dates to reflect in the contract -VA42.

[Former Member]

Hi Raghu,

Thanks for your response...

Here is the process for your understanding.

This process is used in order to rent a cabinet to the concessionaire. The cabinet it is tran-ported physically the concessionaire but it remains under the property of comoany for the period of the agreement of the contract.

Sales Order>Delivery>Pick & GI>Updation of contract throgh a program>Invoice

Now answering to your questions one by one ..

1.The moment any deliveries is created and goods issue is done,immediately this delivery is ready for updating the contract.

I mean numbers of line item in deliveries are added in the contract through the schedule program.

Example:Suppose a Contract X with line item 10000 is existing for a customer A,now if a sales order and delivery is made for customer A and the delivery contains 50 line items then through the scheduled job run the contract gets updated and its line item becomes 10050.

2.No Deliveries are not getting updated.It is only contract which is updated.

3.There is no specific data based on which contract gets updated. The basis is only the delivery and Good issue.

I hope I have answered your question.

Looking for your help

[Former Member]

Hi Raghu,

We are doing the same which you have suggested but facing issues...

The scheduled job is running every night to update a contract for which delivery has been made.

So this program is updating only one contract at a time.Since this contract is containing 10000-50000 line items,so the scheduled job is taking very much time to update a contract.

Once one contract is updated then system starts updating another contract.

So updation of first contract is taking too much time resulting the date change in the system.

Please suggest me another option..

[Former Member]

Hi,

I've some questions, pls help to answer them to help you:

1) What is the criteria when you search the deliveries that are relevant for updation ?

2) Once you've determined what deliveries need to be updated, do you update deliveries as well as contracts?

3) During update, have you identified the most specific data to update like date range, doc type, customer group etc..?

Regards,

Raghu.

[Former Member]

Thanks Raghu for your immediate response.

It is a specific document type which needs to get up dated.

We also worked upon running 3 to 4 jobs in parallel depending upon some parameters with the help of variants but Running these three or four jobs simultaneously will consume memory in S1P and will contribute performance issue in S1P as a whole.

Please suggest some other proposed solutions

[Former Member]

Hi,

Not parallel..but running jobs sequentially one after the other?

Also think of filtering/segregating by dates, sales area and shipping points..?

Regards,

Raghu.

Edited by: Rags on Oct 3, 2011 11:54 AM

[Former Member]

Thanks for your reply

I have checked with the technical person in my team and per his Investigation on the performance issue for the Massive Contract Program Z253408_CONTRACT, upon updating the contract, all items existing on the contract are checked upon saving for changes, and this is a standard behavior in checking the standard table for update (ex: VBAP for item materials and etc..) and thus this causes the runtime error on the contract update on transaction VA42 for the massive update.

In short we did all the analysis on technical part but still could not reach out to solution..

Can you please help me in getting the other proposed solution.

[Former Member]

Hi, One option is if you've, lets say, for 500 contracts..you can split into running 3-4 jobs depending on the time.

Or is there any way, you can determine only the specific documents to be updated?

Let us know, if you've already considered this..we can come up with more options.

Regards,

Raghu.

[Former Member]

Hi srivastava,

I think you have to take the help of technical people,sit with the ABAPer check the program once there you can fine any thing like they might have wrote the program from particular date in the past so from that date only it's giving right input before the date it is not.So take ABAPer help have a look in to the program.

Regards

Ram