Delay in automatic OBD creation after GRN in collective purchase order

[Former Member]

Gurus,

1. For certain articles only, there is a delay in automatic outbound delivery creation once GRN is done for a collective purchase order. The stores raise individual POs to the DC and the DC raises a collective PO to the factory/ manufacturing unit in this case. The delay is in the creation of the OBDs to these individual stores. Please let me know what settings determine this and also maybe the name of the program that creates these deliveries.

2. Also for certain articles, when we run the t-code WF10 to create the collective purchase order, we get the "No documents found" message. Please assist.

Thanks!

Suhas

[Former Member · Accepted solution]

Hi,

When you say GRN is posted, I assume you've confirmed it's actually posted?

How big a delay? Is it just outputting the delivery, or is it calculating the distribution and creating it?

We found we had poor performance on Idoc processing (R/3 4.7) and this was due to merchandise distribution specific code, where by the memory wasn't being cleared during processing of large volumes of data. An OSS note exists for this issue and was relatively easy to apply. I'll try to find the number tomorrow.

On the issue you have on no documents found. Check the STO delivery creation date on shipping data, if the procurement period you have selected in WF10 doesn't include this date, it will be excluded.

We had this issues a lot with poor data setup. We now operate this in batch variant as FROM Today's date - 1 month TO today's date + 2 months.

Without more info it's difficult to advise, WF10 can be a tricky beast to use reliably.

Check out any other OSS notes, as we did apply a few to get working correctly.

Are you configured to use parallel processing in WF10? If so is server group configured correctly? Again another lesson learnt we had.

Hope some of that was of help.

Dave

[Former Member]

Dear David,

Thank you for your reply.

On the delayed distribution, we found that several articles had a large number of old unused batches with zero stock and this was causing the delay. Our archiving experts are looking into this and we will have to archive the object MM_SPSTOCK.

Thanks!

Suhas