Moving the Shopping Cart workflow forward in a approver Rejects a line item

[former_member196491]

Hi Friends,

   We a facing an issue while Shopping Cart Approval process.

We have designed our SC Workflow , with Schema and 4 Process levels. Currently the Approvals are happening fine.

Issue is happening when a Line Item is Rejected by a Single Approver. The Approval process does not move forward.

We need need to move the SC process forward.

Ex: SC: 1000000032

Approval Flow:

ITEM1:  APP01 -> APP02

ITEM2:  APP05 -> APP07

Scenario:01 :

Once APP01 & APP05 approves in first level.  Then APP02 & APP07 approves . Then the process completes.

Scenario:02:

Once APP01 Rejects & APP05 Approves in first level. Then the SC WF does not move forward.

How can I move the WF process forward once a approver rejects.

Need your inputs.

Regards,

Jagan

[laurent_burtaire]

Hello,

check your customizing for "Acceptance by Contact Person" (IMG: SAP Implementation Guide > SAP Supplier Relationship Management > SRM Server > Cross-Application Basic Settings > Business Workflow > Process-Controlled Workflow > Business Process Configuration > Define Process Levels)

For Object Type 'BUS2121' and correct Process Level Schema, Evaluation ID and Task ID should exist for "Acceptance by Contact Person". That's why you have a WI generated to document owner interaction (decision to be checked).

This is managed in workflow template WS40000015 by condition "Decision to be checked?"

For more precision, check below wiki:

Enabling WI returning to the requestor when document is fully rejected

Regards.

Laurent.

[Former Member]

Hi,

the mentioned steps are for a full rejection only. In case of a partial rejection, the standard always sends a workitem, no matter what is maintained in "acceptance by contact person".

The acceptance by contact person Event is only called in case of a full rejection or a full approval.

Markus

[laurent_burtaire]

Hello Markus,

what you describe does not correspond to condition standard determination to know if decision has to be checked or not.

Indeed, this evaluation is done by /SAPSRM/IF_WF_PROCESS_SBWF~IS_DECISION_ACCEPT_REQUIRED method from /SAPSRM/CL_WF_PROCESS_SBWF class.

Inside this method, the default behavior is based on decision of current process level:

- If it is not "rejected" or not "approved" (this means, if it is "inquired"), there is an interaction

- else, there is no interaction.

Then, for "rejected" or "approved" decision, a Business Rule evaluation is done in order to check if the document responsible need to accept the current decision.

If evaluation ID is true, acceptance by Contact Person is required.

I am currently not able to check workflow behaviour for partial rejection when no acceptance by contact person is customized.

I will see this next week.

Regards.

Laurent.

[Former Member]

Hi Laurent,

I agree with everything you write.

But I believe(no time to test) that for a partial rejection(at least one item was rejected and at least one item was approved), the status for the step is INQUIRED. This means that the event which you enter in acceptance by contact person isn't used and instead the workitem is always send.

Markus

[laurent_burtaire]

Hello Markus,

i just checked what you wrote and you are totally correct: for approval level with item-based decision, if at least one item is rejected, approval status is 'INQUIRED'.

So, in standard, the acceptance by Contact Person is required (no need to make any customozing) for partial rejection.

Thank you

Regards.

Laurent.

[Former Member]

Hi Jaganath,

standard behaviour in your scenario two, which is called partial rejection, is that a accept/adjust workitem is send to the requestor of the document. This actually makes sense, since with one item rejected, the other items shouldn't be ordererd as well sometimes(if you reject my new laptop, I won't need to docking station). This decision can usually be made by the requestor, that's why the workitem is send to him.

So basically this is the reason why your workflow get's stuck --> Action from requestor is required, so tell him to look into his inbox.

If you don't want this workitem to be send to the requestor and instead directly reject the item, coding will be required. But how to do it I don't know, never had this requirement(usually this workitem makes sense as explained above).

Markus