PPF Action Definition sends E-Mail notification twice

[Former Member]

Hello together,

We use the PPF action definition for our incident management in solman 7.1.

Our starting condition depends on a status change. In this example we want to send a mail with mail forms to the reporter and our action definition looks like this:

Unfortunately the systems sends the Email notification twice! (But not always) Is there any setting we can use to avoid this behaviour?

However, if the reporter answers to our email and the status (which is linked to the start condition) is set again by the processor an update of the incident should be send "again" to the reporter. Therefore, we didn`t use "max 1 action def." in the action merging field.

Can anyone help?

Many thanks in advance!

Best

Lucas

[Former Member]

Hi everybody,

Many thanks for your input! I really appreciate it.

Update: The e-mail is send twice if the incident processor sets the status "customer action" for the second time, after a reply from customer is received.

Therefore, the setting works fine for the first "customer action" status & save scenario but when the customer answers again (status is then set to "answer from customer") and the incident processor wants to reply with status "customer action" (again), then the email is send TWICE.

Moreover, if I switch the status to "Solution send" after a customer reply is received only ONE mail is generated. Then the customer answers to this mail and the status is set back to "answer from customer". The incident processor replies again with status "Solution send" and the email is generated TWICE.

To be clear: The incident processor saves the incident only ONCE, but the mail gets generated TWICE.

Any suggestions? or a bug?

Best

Lucas

[Former Member]

Hi Lucas,

If you haven't already done so, please check the Scheduled Actions and Processing Log assignment blocks for the Incident where the emails are being sent once/twice. These two logs should shed some light on how your email actions are being processed.

Also can you share for each action (Customer Action and Solution Send) the start and schedule conditions.

Regards

Paul

[Former Member]

Hi Paul,

The processing log indicates that "an identical action has been determined again". But it gives no further information.

We just work with a starting condition for this action and the starting condition is related to the status "customer action" and "solution send".

Details see screenshots:

Best

Lucas

[Former Member]

Lucas,

With your Starting Condition and not using the STATUS_CHANGE parameter in your Starting Conditions, the email should be generated once every time the Incident is saved and in either of your statuses (E0003 or E0005). It won't matter if the status is actually changed or not. Thus, if the Incident is set to 'Customer Action' and saved, the email should be sent. After the customer sets the status to 'Answer from Customer' and the incident processor sets it to 'Customer Action' again and saves, the email should be sent again. However, note that if the incident is already in Customer Action and is saved again for some other reason other than a status change, the email should be sent again. This last issue is why the STATUS_CHANGE parameter might be used. Is this possibly why you're getting the email sent twice?

Regards

Paul

[Former Member]

Hi Paul,

Thanks again for your help.

Unfortunately we only save the incident ONCE and TWO mails are generated. Here is a screenshot of transaction SOST and you can see the two mails, generated in the same second. Today I will try to implement the STATUS_CHANGE BadI, maybe this helps. But I'm not sure about this, because it works fine when I save the incident with status "customer action" for the first time only ONE mail is generated. After the customer reply, the systems automatically sets the status to "answer from customer" and if the processor want to reply again and uses status "customer action" (and only saves 1x) the mail is generated TWICE...

Best

Lucas

[Former Member]

Hi Lucas,

this can usually achieved by using different schedule conditions and start conditions.

For example you can set the schedule condition on status "In process" and "answer from customer".

The start condition would be "customer action".

This means that the action is set ready for execution in status "in process" or "answer from customer" but not yet executed.

If the status then changes to "customer action", the action is executed but not again set ready for execution.

So the action is not executed again if you perform another save in status "customer action".

Best Regards,

Christoph

[Former Member]

Hi Christoph,

Thanks for your input. I set up a schedule condition but unfortunately I get this BSP error when I change the status to "customer action".

After deletion of the schedule condition this error does not occur anymore. Did you face the same error by setting up the schedule condition?

Best

Lucas

[Former Member]

Hi Paul,

I think I dont need a schedule condition as we want to sent a mail everytime we save the incident.

Our problem only occurs if we set back the status to the former status after we receive a customer reply. Can there be a connection between the sap inbound email workflow and the PPF actions? Maybe the worflow adds the reporters email contact somewhere and therefore the PPF action (bound to the partner 'reported by') gets two times the same reporter e-mail adress? Is it possible that this kind of scenario exists?

Best

Lucas

[Former Member]

Hi Lucas,

I have never experienced what you're getting with the duplicate executions of your email action so I'm not sure about the possibility you describe above. What I can do is show you how we've set up one of our Incident email actions, which is triggered once when the Start Condition based on a specific status (E0020) is set.

Action definition:

Action Condition:

Start Condition:

Start Condition parameter:

I also encourage you, if you haven't already done so, to add the Scheduled Actions assignment block to your Incident screen. Use the Wrench   to change your assignment blocks. The Scheduled Actions assignment block is Component GSACTIONS, View Name ScheduledActions. You may need to add it from the Available Assignment Blocks.

If you have this assignment block available, it should be very helpful in displaying every scheduled and executed action which hopefully will help you understand why your email action is executing twice.

Please let me know if you have any questions about any of the above.

Kindest regards

Paul

PS - I tried my email action with and without a Schedule Condition (the same as the Start Condition - User Status = E0020ZMIN0001 and STATUS_IS_NEW = X) and the action email executed once correctly in both cases each time I set the Incident to status E0020 from a different status. If there is no Schedule Condition, then the action is available at all times to be executed but should only be triggered when the Start Condition is met. If there is a Schedule Condition, then the action is not available until that condition is met. You can use Schedule and Start Condition combinations to control your actions quite effectively.

Message was edited by: Paul Maraijko

[Former Member]

Hi Paul,

Thanks to you again for your detailed describtion. I really appreciate it!

However, I took a closer look at the scheduled actions assignment block and it revealed the following (soory, the screenshot is in German):

It seems as if the Worflow-system generates an action (beside my user FANDREYL). Does this support my assumption about the worflow settings in relation to the inbound scenario?

Best

Lucas

[Former Member]

Hi Lucas,

Yes, this seems to support your assumption about the workflow settings in relation to the inbound scenario. I'm sorry but I am not that familiar with SAP inbound email configuration and workflow so I don't think I 'm going to be able to help you much more. Hopefully, others SCN experts can assist with their expertise.

Kindest regards

Paul

[Former Member]

Hi Paul,

Never mind! You helped a lot!

Now I opened a new discussion under: because the title better fits to my problem.

Many thanks again!

Best

Lucas

[former_member186154]

Hello Lucas,

This behavior is expected if you have only maintained a Start condition in the email relevant action.

If it set so then the email is sent every time 'Save' is clicked in the same status.

As it is Incident (probably a copy of SMIN) you can fix this by not having any start condition and by adding a schedule condition with the appropriate status along with the Parameter 'STATUS_CHANGE' = X. This would ensure that the Email is sent only once when the Status change happens to the applicable status.

Regards,

Kathir

[Former Member]

Hello Lucas,

Please check out Note 865619 which provides details on Kathir's solution above.

Kindest regards

Paul

[Former Member]

Hi,

Thanks for your input.

Where do I have to set the parameter (STATUS_CHANGE' = X)?

Can you provide a screenshot?

Best

Lucas

[Former Member]

Lucas,

You set the STATUS_CHANGE parameter in your email action Start and/or Schedule Condition. For example we wanted an email to be sent to the Reported By business partner each time an Incident was set Service Completed status (E0020 for us) but only if the status actually changed to Service Completed from a different status. The Start Condition on our email action looks like this:

Before you can use this you must first create a BADI implementation of CONTAINER_PPF as per the note 865619.

Regards

Paul

[Former Member]

Hello Lucas,

Can you please check the following Blog,

In example 2 its clearly stated that should be as below

Action merging:- Max 1 Action for Each action definition.

Regards

Anand

[Former Member]

Hi Anand,

Many thanks for your quick reply.

However, changing the action merging to "max 1 action for each action definition" only allows ONE action and therefore only ONE e-mail is created (so far, so good). BUT, if I want to add something in the incident and then save again to send another e-mail (with the same action), this does not work anymore, because the action merging is restricted to trigger another action.

We use one specific status to trigger a mail to customer (status: customer action) and if a customer replies the status changes to "answer from customer". If we want to reply to the customer we use the same status as before (status: customer action). Therefore the action merging to "max 1 action for each action definition" does not solve our problem.

I hope my problem is clear to you? If not, please let me know.

Best

Lucas