VF06 - Background job

[Former Member]

Hello Experts,

We are having a requirement to consolidate the deliveries with same PO into a single billing document.

> For this, we have created a custom copy control routine and added customer PO to the ZUKRI field. This is working fine in VF01 or VF04 (Collective billing online).

> But, when we schedule the job using VF06 for almost 90 deliveries with same PO (Payer, Bill-To are same), the split is happening and I am getting billing documents equal to number of different sold-to's. We can have different sold-to here.

> I am unable to figure out why this is happening only with the automatic processing and I am confused if I am missing anything in the job schedule of VF06. I know that VF06 in turn calls VF04 program so was in a thought that VF06 job should work same as VF04 collective billing.

I tried to schedule SDBILLDL with a variant created using SE38 and schedule a new job but this doesn't help though.

I have looked into few posts but could not figure out any particular solution. Same is the case with few notes like 111813, which are not relevant to our release.

Appreciate if anyone can help me with some good inputs.

Thanks,

Sandy

[Former Member · Accepted solution]

You mean 1 billing for 1 sold to?

In billing, do you have soldto party in Header partner?

if yes, you can't combine because all header partner must be the same. So you have to remove Soldto party from your header partner.

If this is not about soldto, then try VF01 with 2 different OB and check the split log and give us the screen shot.

[Former Member · Accepted solution]

Hi Alan,

Thanks for the response.

The customer has maintained many sold to's for them. But the Payer and Bill to would be the same for all sold-to's. Yes, we are clearing the sold-to value in the copy control routine.

This is working and consolidating fine when processed all 90 deliveries through VF01 and VF04 (collective billing online). We are getting a split only when we run the job using VF06. So, when I see the billing documents created, there are 90 deliveries and 6 sold-to's and I see 6 different billing documents are created with different sold-to's. I can't see the log of this job process.

The main issue is - It is working fine in VF01 and VF04 but not through VF06. VF06 must be the same process as VF04 but not sure whats going on.

Please let me know if you see anything.

Thanks,

Sandy

[Former Member · Accepted solution]

What I mean is do you have SoldTo Party in your header partner? If yes, please remove in your partner configuration.

[Former Member · Accepted solution]

Oh, yes, and you should also check out this OSS 25147

[Former Member · Accepted solution]

Hello Alan,

Thanks for your time and responding to me.

We are good at the config side. If there is something we are missing in the config, then the online process through VF04 should also split but it is working as we needed (consolidating all the deliveries with same PO and creating a single invoice).

I finally figured out a solution for this.

VF04 - Online processing looks the split criteria based on the copy control routine.

VF04 (background) or VF06 - This also executes the copy control routine BUT, there is a function module 'SD_COLLECTIVE_RUN_EXECUTE' which is triggered ONLY during the background process. So, in this FM the invoice document split is again happened based on different sold-to's.

Finally, I could find a user exit above this split and I could clear the sold to value. It works perfectly now in background process too.

I would like to thank Shiva for that note. It actually explains similar logic.

Thanks everyone for your time in responding to my post.

Thanks,

Sandy

[mgbernardo · Accepted solution]

Hi Sandy,

We are facing the same issue. Could you please tell us in which user-exit did you clear de SoldToParty and how did you do it?

Thanks in advance!

Regards

[Shiva_Ram]

Check OSS   1561427 - Billing document split  cause 2 applies to your scenario.

Regards,

[Former Member]

Hi Shiva,

Thanks for the response.

I did see the note and cause mentioned in your post. But, there is not code maintained in the user exit so I don't think this cause would apply.

Thanks,

Sandy