Workflow: Release Requisition (MM-PUR-REQ)
If the system recognizes that the release code with which a user must next signify approval in accordance with the release strategy is workflow-relevant, a workflow is started. An individual workflow is started for each workflow-relevant release code. A central task of workflow control is to determine the processor (several may be involved) to whom this release code has been assigned.
When are workflows started in the case of release strategy KF?
When user MILLER, or alternatively user GRITPIPE (both Technical Services), have released a requisition item with their non-workflow-relevant release codes T1/T2, the requisition item must then be processed with release code KY. Since KY is workflowrelevant, a workflow is started. The system recognizes that release code KY has been assigned to user SEAGOON (Sales Manager) and creates a work item for the latter.
When are workflows started in the case of release strategy TF?
A workflow is started as under release strategy KF. When user SEAGOON releases the requisition item, a further workflow is started and a workflow item appears in the inbox of user HUBBARD (Executive Board).
Item-Wise Release
Workflow: 00000038
Identifier: wf_req_rel
Description: Workflow for requisition release
Overall Release
Workflow: 20000077
Identifier: wf_req_rel_c
Description: Workflow for overall release of requisition
Triggering Event for Workflow
The event ReleaseStepCreated has been entered as the trigger for the workflow for the relevant object type.
This “linkage” between the event and the workflow to be triggered is deactivated in the standard system and must first be activated in Customizing for SAP Business Workflow if the workflow is actually to be started.
Workflow Container and Data Flow
The most important information that must be available within the course of the workflow comprises the reference to the purchase requisition to be processed (_EVT_Object) and the release code (ReleaseCode), as well as the name of the person who the created the purchase requisition (_EVT_Creator). The information is available as an event parameter in the container of the triggering event and must be passed on from there to the workflow container via data flow.
Therefore, the following data flow definition between the triggering event and the workflow container is defined in the standard system:
Workflow container Event container
_WF_Initiator <- _Evt_Creator requisition <- _Evt_Object ReleaseCode <- ReleaseCode In the standard system, the element _WF_Initiator exists in the workflow container. The elements requisition and ReleaseCode have been created in addition to the standard elements that exist. Steps in a Workflow (MM-PUR-REQ) If the release code with which the complete purchase requisition or the requisition item is to be processed according to the release strategy is workflow-relevant, a workflow is started and a release work item generated.
If a user whom workflow control identifies as being responsible for this release code logs on to the system, this user will see this work item in his or her SAP Business Workplace inbox. If, for example, a job is assigned to the release code as a processor ID and several users are allowed to work with this release code, all of these users will see the same work item in their inboxes. An individual workflow is started for each workflow-relevant code. The processing of the work item results in one of the events Release refused or Release effected. These events terminate the task Release requisition. The entire workflow is ended when the creator of the purchase requisition receives a confirmation via a work item and has processed this work item.
The terminating event Requisition significantly changed can also occur outside the workflow process. Changes After the Start of the Release Procedure Changes to a purchase requisition can only be made if no other user is currently processing the requisition and the requisition has not yet been converted into a purchase order or RFQ. In the following, we discuss what happens when a purchase requisition for which the release procedure has already commenced is changed. The following possible situations may arise: Changes that do not necessitate a different release strategy Significant changes necessitating a different release strategy Since the first case does not necessitate another release strategy, it will not be discussed further here. Significant change The number of PCs requested for Asset 3221 is increased to 5. As a result, the total value of the requisition item increases to $12,300. It is not possible to simply go ahead and make this change.
The system issues a message; the release strategy must be re-determined (TF) and the release procedure restarted from the beginning. If the change is significant, the right-hand path in the graphic would thus be taken, and the workflow terminated due to the occurrence of an event external to the workflow process. This has the following consequences: If the requisition has already been released for the issue of an RFQ or a PO, it is blocked again by the application and must be processed in accordance with the new release strategy. If a work item was generated, it is no longer visible in the processor’s SAP Business Workplace inbox. Workflow Definition: Details (MM-PUR-REQ) The following details are of interest in connection with the definition for the workflow for releasing (approving) purchase requisitions. Look at the definition in the system. Data Flow The following data flow is defined for each of the steps Release requisition, Confirmation of refusal and Confirmation of release: Task container Workflow container _WI_Object_ID <- requisition ReleaseCode <- ReleaseCode The elements Requisition and ReleaseCode have been created in the workflow container in addition to the elements available in the standard system and are supplied from the triggering event. Determining the Processor The processor determination facility is stored in the tasks (Release of Purchase Requisition) and not in the workflow definition. See Tasks: Release of Requisition (MM-PUR-REQ).Result of Processing and Termination of Workflow Once the user has processed the complete purchase requisition or requisition item using his or her release code, one of two results is possible: either the requisition or requisition item has been released or release has been refused. This status information is placed in the SAP Business Workplace inbox of the requisition creator (_WF_Initiator) as a work item.
When this work item has been processed, the workflow is terminated. The terminating event Requisition significantly changed can also occur outside the workflow process. Release Procedure with Classification Requisition release with a link to SAP Business Workflow can only be carried out using the release procedure with classification. For this, all characteristics that are used in the release conditions (e.g. plant, purchasing group, account assignment category etc.) must be defined in the classification system. Customizing the Workflow Several other specific customizing steps are necessary for this workflow in addition to the general customizing that is necessary to make sure that the workflow system functions properly. The following graphics give an overview of the settings that have to be maintained in Customizing. Customizing of SAP Business Workflow You can replicate your enterprise structure in the SAP System using the organizational plan.
You create this structure in Customizing with elements such as organizational units (e.g. Executive Board, U.S.A) and positions (e.g. Board Member, Sales), and assign position holders (e.g. Hubbard) to these positions. In this way, you define the possible release points in the system. Organizational Plan Member of Executive Board, Sales . . . Hubbard Executive Board, U.S.A. . . . Seagoon Production and Sales, U.S.A. Sales Manager SAP supplies predefined tasks (e.g. TS 00007986: Release of Purchase Requisition). You must assign possible processors to these tasks. You can assign these tasks to a release point (position or user) or allow every employee to perform them by defining them as “general tasks”.
RELATED POSTS
WORK FLOW IN MM PART 5
SAP web application and business server pages
SAP project introduction in the best ERP
SAP project migration
If the system recognizes that the release code with which a user must next signify approval in accordance with the release strategy is workflow-relevant, a workflow is started. An individual workflow is started for each workflow-relevant release code. A central task of workflow control is to determine the processor (several may be involved) to whom this release code has been assigned.
When are workflows started in the case of release strategy KF?
When user MILLER, or alternatively user GRITPIPE (both Technical Services), have released a requisition item with their non-workflow-relevant release codes T1/T2, the requisition item must then be processed with release code KY. Since KY is workflowrelevant, a workflow is started. The system recognizes that release code KY has been assigned to user SEAGOON (Sales Manager) and creates a work item for the latter.
When are workflows started in the case of release strategy TF?
A workflow is started as under release strategy KF. When user SEAGOON releases the requisition item, a further workflow is started and a workflow item appears in the inbox of user HUBBARD (Executive Board).
Item-Wise Release
Workflow: 00000038
Identifier: wf_req_rel
Description: Workflow for requisition release
Overall Release
Workflow: 20000077
Identifier: wf_req_rel_c
Description: Workflow for overall release of requisition
Triggering Event for Workflow
The event ReleaseStepCreated has been entered as the trigger for the workflow for the relevant object type.
This “linkage” between the event and the workflow to be triggered is deactivated in the standard system and must first be activated in Customizing for SAP Business Workflow if the workflow is actually to be started.
Workflow Container and Data Flow
The most important information that must be available within the course of the workflow comprises the reference to the purchase requisition to be processed (_EVT_Object) and the release code (ReleaseCode), as well as the name of the person who the created the purchase requisition (_EVT_Creator). The information is available as an event parameter in the container of the triggering event and must be passed on from there to the workflow container via data flow.
Therefore, the following data flow definition between the triggering event and the workflow container is defined in the standard system:
Workflow container Event container
_WF_Initiator <- _Evt_Creator requisition <- _Evt_Object ReleaseCode <- ReleaseCode In the standard system, the element _WF_Initiator exists in the workflow container. The elements requisition and ReleaseCode have been created in addition to the standard elements that exist. Steps in a Workflow (MM-PUR-REQ) If the release code with which the complete purchase requisition or the requisition item is to be processed according to the release strategy is workflow-relevant, a workflow is started and a release work item generated.
If a user whom workflow control identifies as being responsible for this release code logs on to the system, this user will see this work item in his or her SAP Business Workplace inbox. If, for example, a job is assigned to the release code as a processor ID and several users are allowed to work with this release code, all of these users will see the same work item in their inboxes. An individual workflow is started for each workflow-relevant code. The processing of the work item results in one of the events Release refused or Release effected. These events terminate the task Release requisition. The entire workflow is ended when the creator of the purchase requisition receives a confirmation via a work item and has processed this work item.
The terminating event Requisition significantly changed can also occur outside the workflow process. Changes After the Start of the Release Procedure Changes to a purchase requisition can only be made if no other user is currently processing the requisition and the requisition has not yet been converted into a purchase order or RFQ. In the following, we discuss what happens when a purchase requisition for which the release procedure has already commenced is changed. The following possible situations may arise: Changes that do not necessitate a different release strategy Significant changes necessitating a different release strategy Since the first case does not necessitate another release strategy, it will not be discussed further here. Significant change The number of PCs requested for Asset 3221 is increased to 5. As a result, the total value of the requisition item increases to $12,300. It is not possible to simply go ahead and make this change.
The system issues a message; the release strategy must be re-determined (TF) and the release procedure restarted from the beginning. If the change is significant, the right-hand path in the graphic would thus be taken, and the workflow terminated due to the occurrence of an event external to the workflow process. This has the following consequences: If the requisition has already been released for the issue of an RFQ or a PO, it is blocked again by the application and must be processed in accordance with the new release strategy. If a work item was generated, it is no longer visible in the processor’s SAP Business Workplace inbox. Workflow Definition: Details (MM-PUR-REQ) The following details are of interest in connection with the definition for the workflow for releasing (approving) purchase requisitions. Look at the definition in the system. Data Flow The following data flow is defined for each of the steps Release requisition, Confirmation of refusal and Confirmation of release: Task container Workflow container _WI_Object_ID <- requisition ReleaseCode <- ReleaseCode The elements Requisition and ReleaseCode have been created in the workflow container in addition to the elements available in the standard system and are supplied from the triggering event. Determining the Processor The processor determination facility is stored in the tasks (Release of Purchase Requisition) and not in the workflow definition. See Tasks: Release of Requisition (MM-PUR-REQ).Result of Processing and Termination of Workflow Once the user has processed the complete purchase requisition or requisition item using his or her release code, one of two results is possible: either the requisition or requisition item has been released or release has been refused. This status information is placed in the SAP Business Workplace inbox of the requisition creator (_WF_Initiator) as a work item.
When this work item has been processed, the workflow is terminated. The terminating event Requisition significantly changed can also occur outside the workflow process. Release Procedure with Classification Requisition release with a link to SAP Business Workflow can only be carried out using the release procedure with classification. For this, all characteristics that are used in the release conditions (e.g. plant, purchasing group, account assignment category etc.) must be defined in the classification system. Customizing the Workflow Several other specific customizing steps are necessary for this workflow in addition to the general customizing that is necessary to make sure that the workflow system functions properly. The following graphics give an overview of the settings that have to be maintained in Customizing. Customizing of SAP Business Workflow You can replicate your enterprise structure in the SAP System using the organizational plan.
You create this structure in Customizing with elements such as organizational units (e.g. Executive Board, U.S.A) and positions (e.g. Board Member, Sales), and assign position holders (e.g. Hubbard) to these positions. In this way, you define the possible release points in the system. Organizational Plan Member of Executive Board, Sales . . . Hubbard Executive Board, U.S.A. . . . Seagoon Production and Sales, U.S.A. Sales Manager SAP supplies predefined tasks (e.g. TS 00007986: Release of Purchase Requisition). You must assign possible processors to these tasks. You can assign these tasks to a release point (position or user) or allow every employee to perform them by defining them as “general tasks”.
RELATED POSTS
WORK FLOW IN MM PART 5
SAP web application and business server pages
SAP project introduction in the best ERP
SAP project migration
No comments :
Post a Comment