Scheduling Automatic Payment Program Error.

[Former Member]

Hi Experts,

I have created a varient in F110S for APP as on Payment date as 09.04.2013 with Identification as "FITVY" with all other required field entered. Now i have created a Job and schedule the Program every date.

On 09.04.2013 all the Open item for the Vedor have been cleared and the Job ran Succesfully. But the Next day i.e., on 10.04.2013 the Job status was in Canceled status  when I looked into the Job Log it says Identification Already Exist.

I would like to know how to schedule APP through Job or is there any steps i am missing.

Regards,

Raziq Fareed.

[Former Member · Accepted solution]

Hi,

I guess, the reason could be date fields (posting date, docs entered upto etc).

Could you please let us know if you had selected dynamic date selection for date fields.?

If the dates are entered manually in F110S, they would not change automatically when the second and subsequent runs are performed. You need to select dynamic date selection in the variant that is used for periodic jobs.

To select dynamic dates: In varaint screen, against date field scroll right to field selection variable > select dynamic date selectin > In the same row, navigate to Name of variable field and select the appropriate variable.

Regards,

Ravi Kumar

[Former Member · Accepted solution]

Hi Ravi,

Thanks for the solution proposed, I am testing the APP process with the dynamic date selection but do we need to Set the dynamic date for Next posting date as well ?

Kinldy let me know on this.

Regards,

Raziq Fareed

[Former Member · Accepted solution]

Hi,

Yes, you need to set a dynamic date for even next posting date, however, this date would not cause the error you are facing.

The error is due to duplication of combination of Run ID and Identification in the second and subsequent runs. You can check, if this is the case for your first payment run executed successfully and the next rurns faced errors.

Go to SM37 > Select the background job > Step > Go To > Variant.

Compare the variants of both the jobs to identify if the combination of Run ID and Identification is unique in both the cases.

Also please let us know if you are running this background job more than once in a day using the same variant.

Regards,

Ravi Kumar

[Former Member · Accepted solution]

Hi,

Thanks for the solution provided. 1 More Q ,is it possible to run the APP job with the same variant every 30 mins in a same day?

If possible let me know now ?

Regards,

Raziq Fareed.

[suma_mani · Accepted solution]

Hi Raziq,

Yes,ofcourse You can select other periods in period values tab (Bottom left) ,enter 30 Minutes in selection tab while scheduling the job.

[Former Member · Accepted solution]

Hi,

Its not possible to use the same variant more than once in a single day, because the combination of Identification and Run Date have to be different for each run. If not, you would face the error saying that this run is already existing.

In your case, if you create multiple background jobs in a same day using the same variant, the run date remains the same throughout the day. And the Identification would remain same in all the runs (for all the days) unless you define the Identification field as a dynamic one in your variant. I have never tried defining the identification as dynamic. Hence, at this moment I can suggest the following.

Create as many varaints as many times you want to execute payment run in a single day. So, copy the existing variant to create multiple variants. Make sure that Identification is different in each of these variants and you can have the same Run Date.

For each run in a day you will have to create a variant.i.e. if you wish to run the payment cycle 10 times a day, create 10 variants wherein the Identification field is different in each variant even though the Run Date is constant.

Regards,

Ravi Kumar

[Former Member · Accepted solution]

Hi,

Thanks for the update, I want to know using the same screen varient in APP can we schedule the job every 30 min ?

Regards,

Raziq Fareed.

[Former Member · Accepted solution]

Hi Ravi,

Thank you for the valuable inputs, my issue is solved.

Regards,

Raziq Fareed

[Former Member · Accepted solution]

Hi,

Glad that the isseu is resolved...

Just want to know what exactly was the problem... Just curious to know.

Regards,

Ravi Kumar

[former_member198032]

Hi,

1. How can avoid to have jobs started which will conflict?

2. If we get question 1 solved, then we can also skip our waiting steps,

as next steps will start when previous step really is finalized.

You can call report RFF110S for following cases:

1. To create parameter for SAPF110S and to start a proposal run!

2. To create parameter and to start a payment run immediately!

3. To start the payment run if a proposal exist already!

There are not any other functions!

Although you have to pay attention, that a proposal run or a payment run

will be started as batch jobs in any batch task, if such a free batch

task exist. The job with the reports RFF110S etc. is blocking such a

batch task furthermore if there are any WAIT steps.

You are right too, that proposal run or payment run can run a short time

only, but can run a very long time too.

At last step in the proposal run the payment program updates the table

entry REGUV by REGUV-XVORE = 'X'. This will be checked in RFF110S too.

If parameter already exist and a payment should be started, but

REGUV-XVORE <> 'X', than F0379 with 'Run Identification Already Exists'

will be displayed.

At last step in the payment run the payment program updates the table

entry REGUV by REGUV-XECHT = 'X'.

But this does not mean, that all functions of payment program will be

ready. You know, normally the payment documents will be posted

asynchronous. These postings could be take more time than the run time

of the payment program. That's why "payment document validation" is

important for creation of payment medium (see topic 4 of note 545340).

As described there, the update is complete if the number of posting

orders created (REGUV-ANZER) corresponds with the number of completed

posting orders (REGUV-ANZGB) in transaction F110. But a simple check

does not exist, if any posting terminates and will be visible by SM13.

Best regards,

Cristiano

[martins_jurcenko]

Hi Raziq Fareed,

Check in F110 if for 10.04.213 the payment run ID with same name and date exists and browse the log to see who and when executed it.

Then try scheduling new job and use your own unique ID - so that you can test same scenario for longer period.

Here is some KX from help:

Next Posting Date is needed in order to check the due date of payables. If an item is already overdue on the date of the next payment run, or would lose cash discount, the system pays the item in this payment run.

The general rule for receivables is that they cannot be paid until the baseline date for payment has been reached. Such items are paid on or after the baseline date for payment, regardless of when the next payment run is scheduled for.

Thanks,

Martins