Skip to Content

BS02-Status profile

Hi All,

I m tring to create a new status profile to my sales document but

when I come to the last status which means ´´closed´´ the ATP quantities are not still reserved to my sales document.

Is there any business transaction in BS02 which can be used that the ATP quantities get free?

Thanks in advance and best regards

L

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Oct 28, 2010 at 06:54 AM

    Hi,

    Overview:

    The User Status Management functionality is provided to extend the Element Approval workflow with certain additional features. These features involve extending the behavior of the Elements with customized status values in addition to the standard Element status values provided by SAP Document Builder.

    In the standard workflows delivered by SAP in Document Builder, the element can be Draft, In Approval, Inactive, or Active. The User status management functionality allows the user to extend this status schema with additional status values that he wishes to add to control the workflow steps. It consequently controls the behavior of the Element in each of these states. The status management logic is developed to utilize the standard status management framework provided by SAP to manage the User status.

    The User Status framework:

    The SAP basis already provides a framework to maintain and configure a user status with transaction BS02 (Table TJ30). This transaction allows you to define a so called status profile that is linked to a certain object type (e.g. contract header, contract item, business partner, partner data).

    Within a user status one can then define different status settings with one marked as initial status. Each status has a status number assigned to it that allows you to restrict the range of follow-on statuses that can be set.

    Each status can be configured to control a certain set of business transactions.

    The way the original N-step Element Approval workflow works:

    The original N-step Element Approval workflow is triggered when the Element status changes from 'Draft' to 'In Approval' i.e. when the Element is released in the Cockpit. The workflow takes the Element through multiple Approval steps (based on the number of Approvers assigned to it) and finally pushes the Element into 'Active' state if it is approved by all the listed approvers. If any of the approvers reject the Element, it goes into the 'Inactive' status and the workflow terminates.

    During all the approval steps, the status of the Element is always 'In Approval'. The approvers are assigned to the Element via its Element category through the IMG settings. It is also possible to have multiple approvers for the same Element category and define a sequence in which the work item is sent to each user for approval. We can assign the approvers to the Element at the runtime as well during the Element creation in the Cockpit. It is done through the Workflow tab on the Element creation screen in the cockpit.

    There is also a BADI /IPRO/WFL_APPROVAL which can be used to modify the list of Approvers that are assigned to the Element. This provides some more flexibility for having the Element assigned with Approvers dynamically based upon its characteristics at runtime.

    The way the new workflow would work:

    The need for this new workflow is felt due to the availability of the Status Management framework provided by SAP. We could have the Element assigned with Custom status values apart from the standard ones (Draft, In Approval, Active) depending upon the customizing. This customizing can be done using a framework provided by SAP (transaction BS02). In this customizing we define a status profile and a sequence of status values assigned to this status profile. Once we attach the status profile to a Business Object (like Element), the business Object can be assigned with these status values according to the defined sequence. The biggest advantage of having custom status values is that we can control the behavior of the Element based on its status at runtime. For instance, we can prevent the Element from being edited for particular status values and allow this action for some statuses.

    Once we have a status schema defined (using transaction BS02), we can use this status schema for an Element workflow.

    Prerequisites:

    1) Activate the use of User Status Management by maintaining the configuration parameter 'USER_STAT_ACTIVE' at the content level in IMG. The coding done for user status management is executed only if this parameter is set.

    2) Make sure that the correct workflow is active for the event 'INAPPROVAL' of class /IPRO/CL_WF_ELEMENT.

    3) Ensure that only one workflow has the triggering event 'INAPPROVAL' of class /IPRO/CL_WF_ELEMENT activated.

    4) Implement the BADI /IPRO/WFL_USRSTATUS method CHANGE_STATUS_PROFILE to make sure that you initialize the status profile value in this method. Here we can assign the status profile value based on the Element category or write any such custom logic to choose the status profile value based on element characteristics.

    5) Implement the BADI /IPRO/WFL_USRSTATUS method CHANGE_ELEMENT_UI to customize the element UI components based on the User status. For instance, we can enable the 'Edit' button for the status 'In Translation' and disable it for other status values.

    6) If you are implementing your own Custom Workflow for Element, it is necessary that the workflow has the following Container elements:

    (a) ELEMENT

    (b) APPROVER

    (c) APPROVAL STEPS

    The workflow starts when the user would release the Element. Typically the initial status of the Element would be Draft (or whatever is defined in the status schema using BS02). Once the user releases the element, the element is pushed into the next appropriate state (defined in the sequence for the status profile using BS02) and the workflow starts executing.

    It is very important that before the workflow terminates successfully, the element is made active by calling 'RAISE_ACTIVE' on the Element workflow object. This should happen after all the approvers approve the element. This can be achieved using the task TS40407930.

    Triggering the Workflow:

    Since the logic for triggering the workflow is somewhat rigid and has other dependencies, it is difficult to have a workflow triggered using custom events. Hence the workflow has to be triggered on the event INAPPROVAL of class /IPRO/CL_WF_ELEMENT. In the situation where we need different process flows based on Element characteristics (like Element Category), we need to implement multiple branching within the same workflow based on a container element value.

    Agent Determination:

    Rules can be written to assign the approver to a particular approval step based on Element characteristics obtained from the Workflow container during the workflow execution. A rule contains a Function module which is nothing but the logic for Agent determination based on the Element characteristics like Element Category, cmodif etc. Mapping can be defined between the Rule container and Workflow container to transfer the values between workflow and the Function module that determines the Agents. Document Builder delivers the Rule 40400139 which uses the Approvers in the APPROVER container element in the sequential order. But you can write your own rule and write your custom logic using other container elements to determine the agents to process the respective work items.

    Determining the Next Status:

    During the workflow execution, the Element has to be pushed to the next appropriate user status depending upon the user's action. This can be achieved by calling the NEXT_STATE method on the /IPRO/CL_WF_ELEMENT object in the workflow. This can be achieved using the task TS40507963. This method call pushes the Element to the next state (that is defined in the status profile using the transaction BS02). Thus it helps the workflow to guide the Element through the various status values as defined in the status profile.

    Jumping to the Initial Status:

    During the workflow execution it is also possible to jump to the Initial User status of the previous User status in the sequence (i.e. status profile). This can typically happen when the user rejects the element change and the Element needs to be pushed to the previous or initial status to re-do the processing. This can be done using the methods SET_INIT_USRSTAT and PREV_STATE in the Element workflow class /IPRO/CL_WF_ELEMENT. To achieve this we can use the tasks TS40507962 (to set Initial status) and TS40507964 (to go to previous state).

    Setting the Status profile:

    It is quite possible that we may require different status profiles for different categories of elements. In transaction BS02, we can define multiple status profiles. To enable the linking of correct status profile to an Element at the runtime, we can use the BADI /IPRO/WFL_USRSTATUS to determine the status profile for an Element based upon its attributes at runtime (such as Element category). For example, we can code the BADI method CHANGE_STATUS_PROFILE to set the status profile as follows:

    SELECT SINGLE * FROM /ipro/telmnt INTO wa_element

    WHERE guid = iv_guid.

    MOVE-CORRESPONDING wa_element to ls_element.

    lv_content = wa_element-content.

    CALL FUNCTION '/IPRO/CONTENT_FACTORY'

    EXPORTING

    piv_name = lv_content

    IMPORTING

    pet_contents = lt_content.

    READ TABLE lt_content INDEX 1 INTO wa_content.

    lo_content = wa_content.

    lo_factory = lo_content->get_element_factory( ).

    lo_user_elm ?= lo_factory->build_img_instance( PIS_ELEMENT = ls_element

    piv_build_type = '1').

    lo_vers_elm ?= lo_user_elm.

    wa_element = lo_vers_elm->get_telmnt_row( ).

    If wa_element-elm_category eq 'ZLOCAL'.

    Cv_stsma = 'YWFLOC'.

    ELSEif wa_element-elm_category eq 'ZGLOBAL'.

    Cv_stsma = 'YWFGLOB'.

    ENDIF.

    This logic shouldn't be confused with the status profile determination decision that is needed to be taken in the workflow itself. We need to provide multiple branches in the workflow to handle different status profiles and it is necessary to do so. The BADI helps the other components (such as the WD views displaying the User status) in determining the correct User status.

    Modifying the UI based on User Status:

    We may need to have different UI behaviors based upon the current user status value. It is possible to define a custom logic to control the behavior of UI components based upon the user status values. For instance, we need to have the Element editable for a certain user status but not for others. We can make use of the BADI /IPRO/WFL_USRSTATUS method CHANGE_ELEMENT_UI to achieve this.

    For example, we can enable the 'Edit' button on the Element view for a certain User status and disable it for others as follows:

    data lo_edit type ref to cl_wd_button.

    lo_edit ?= io_view->get_element( 'EDIT' ). "reference to a UI component

    check lo_edit is not initial.

    check iv_stsma eq 'ZLOCAL'. "check status profile

    case iv_estat.

    when 'E0003'.

    lo_edit->SET_ENABLED( abap_true ).

    when OTHERS.

    lo_edit->SET_ENABLED( abap_false ).

    ENDCASE.

    Determining the final Status (Counting the status values in a profile):

    It is not directly possible to determine if you have reached the final step of the status definition. But you can write your own logic to determine the number of steps that you have defined for your status profile. This can be done as follows:

    During the Workflow execution, you have access to the container element APPROVALSTEPS. This element can be used as the count of approval steps that you can have in your workflow and you can use it in your own way in the workflow to determine the last step.

    How to populate this container element -> To fill this container element with the number of Approval steps, one can use the BADI /IPRO/WFL_APPROVAL method CHANGE_ELEMENT_APPROVER to write your own logic and fill the internal table ct_agents with the approvers required for each stage in the workflow. The element object is passed as a parameter to this method. You can determine the element category from this object and also the status profile for that element category. Once you get the status profile, you can retrieve all the steps and fill the ct_agents table with an entry for each step. The container element APPROVALSTEPS is the count of the number of entries in ct_agents table.

    The Summary of additional Components developed:

    Workflow:

    WS40500038

    Tasks:

    TS40507962 task to reset status

    TS40507963 task for next status

    TS40507964 task for previous status

    BADI:

    /IPRO/WFL_USRSTATUS

    regards,

    balajia

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 15, 2010 at 08:55 AM

    not solved

    Add comment
    10|10000 characters needed characters exceeded