PO on HOLD? – HOLD Workflow Triggering

[Former Member]

This document explains the scenario of triggering the workflow on creation of Purchase Order (Only if the PO is having the release strategy).

The business was facing the below obstacles as mentioned

Problem Description:

• The workflow was not working properly when the user puts the PO on Hold (with missing cost center for example).
• Then when the user completes the PO by saving (after entering the cost center details), the workflow is not triggered.

  Assumptions: 

• The workflow is already built and it working fine in normal scenarios as per the client requirement.
• The problem occurred when the PO is put on hold and the saved after making necessary changes to PO.
• The triggering event used for the workflow is BUS2012.RELEASESTEPCREATED (as it needs to be triggered only when the release strategy is there for a PO)

Observations:

As I was searching for the possible solution in the internet, programmers in most of the blogs suggested to use the BUS2012.CREATED event (will be triggered when the PO is created). But in my case I do not want to trigger my workflow each time a PO is created, the workflow has to be triggered only when the PO created and it is having a release strategy.

Let us create a PO and put it in hold status to understand the problem in better way

Transaction: ME21N (Create PO).

Now the PO is in hold status, we now make some changes (not mandatory), and save the PO (as shown in screen below).

NOTE : As we can see that the PO which was kept on hold has been saved. While performing this the event BUS2012.CHANGED has been triggered and not BUS2012.CREATED. So the answer I found in the blogs to use BUS2012.CREATED as a triggering event will not work in this scenario.

Possible Solutions:

1. The workflow needs to be triggered even when the PO is kept on hold with the proper data (Ex:-Findind the approver, Triggerring mail to appropriate approver, Sending work item to approver’s inbox etc..) but all these processing should begin only when the PO changed to status unhold (Changed).
2. The workflow should not be triggered when the PO is kept on hold, it needs to be triggered only when the PO is in unhold status and the functionalities of the workflow should be unaltered.

Let us choose the second solution because it sounds simple and logical enough to implement.

As per choosen option, the first thing will be finding whether the PO is in hold status or not in table level. The EKKO (Purchasing Document Header) table is having a field MEMORY(Purchase order not yet complete), it will be having a value ‘X’ if the PO is not complete (hold).

Please find the screen below

This field will be blank once the PO is changed to unhold (created successfully) status.

Ex :-

Now, we are already using the triggerring event BUS2012.RELEASESTEPCREATED along with that we also need to use the event BUS2012.CHANGED.

Now every time the PO is changed, the workflow will be triggered we need to control this because our intention is to triggered the PO only when the PO is not in HOLD status.

  We can use a start condition for the workflow using the field ‘Purchase Order.Release Status’ this flag will be ‘X’ if the PO is saved perfectly, otherwise it will be blank (if the PO is kept on hold status). The start condition used as follows

From the change we incorporated above the workflow will not be triggered when PO is kept on hold.

In general there will be scenario the PO might required to changed after it has been created, for example updating the net amount, changing the purchase group etc..

Currently in our case workflow will be triggered everytime there is a change PO. We need to restrict this because PO change scenarios will be handled in later stages of the workflow (if we do not restrict, all these scenarios needs to handled immediately after triggering the workflow. Will be complicated).

To achieve this an attribute needs to be created in the delegated BOR where the flag will be set based on the changes happened to the PO.

The changes to the PO can be found on the table CDHDR (Change document header) and CDPOS (Change document items).

The workflow triggering can be stopped each time the PO is getting changed once it is saved. So will trigger the workflow based on the follwing logic.

” Retrieving the latest change done to the PO from CDHDR

SELECT MAX( changenr )
FROM cdhdr
INTO lv_changenr
WHERE objectid = object-key “ PO number
AND   username NE ‘WF-BATCH’. “ Olny if not triggered by the system

IF sy-subrc = 0.
** Checking if the PO was on hold from CDPOS
SELECT fname
value_new
FROM cdpos
INTO TABLE lt_cdpos
WHERE objectid = object-key
AND   fname    = ‘MEMORY’ “ Field name
AND   changenr = lv_changenr  “ Value from CDHDR
AND   chngind  = ‘U’.                         “ Updated
IF sy-subrc = 0.

FLAG = abap_true.

     ELSE

FLAG = abap_false.

ENDIF.

ENDIF.

Now we will use this flag value in the workflow start condition in the CHANGE triggering event of the workflow. The WF should be triggered only when the FLAG is set to ‘X’ it means that the MEMORY field value has been changed while updating the PO.

Conclustion:

We tracked the latest changes done to the PO and in that latest change we are checking wether the PO is crated form its previous hold status. If so we are settign the flag and we are using this as a start condition. If MEMORY field is not present in the latest change we are not triggering the workflow.

NOTE : The remaining conditions can be handles based on the business requirement.

============================== THANK YOU =====================================