WORK FLOW SCENORIOS IN MM 3

Release Procedure with Classification and Workflow

(MM-PUR-REQ)

The following graphic illustrates the implementation of a release procedure with a link to workflow using the release strategy KF as an example. Since the Sales Manager is seldom required to release requisition items, his or her release code is workflow-relevant. That is to say, in such cases a work item will appear in the integrated inbox of the processor responsible for this code.

Process Flow

1. The characteristic values from the complete purchase requisition or the requisition item are passed on to Classification.
2. The system checks whether the values satisfy release conditions. If so, it assigns a release strategy (in the example, KF). The release strategy is determined independently of SAP Business Workflow.
3. The persons responsible for the release codes process the complete purchase
requisition or the requisition item in the sequence prescribed by the release strategy.

In the case of strategy KF, the sequence is as follows:
Once the strategy has been assigned, the employees from the technical department (T1
and T2) see the requisition item in their worklist of requisitions requiring release. When one of these employees has effected release, the Sales Manager (KY) sees a work item in his or her SAP Business Workplace inbox. Once the Sales Manager has signified
approval, an RFQ or a purchase order can be issued.


If the Sales Manager refuses to release the item, no further processing can take place and the requisition item may have to be amended.

If strategy TF is assigned, processing is basically carried out as in the case of
strategy KF except that an additional work item is generated after the Sales Manager
(KY) has effected release. This work item appears in the inbox of the relevant
member of the Executive Board (EX).

If the Sales Manager (or afterwards the member of the Executive Board) refuses to
release the item, no further processing can take place and the requisition item may
have to be amended.

An individual workflow is started for each workflow-relevant release code.

Object Types Used

Object technology is used to create the interface between the SAP functionality and the Workflow system. The information given below is primarily of a technical nature and is not necessary for an initial overview.

Tasks

The single-step tasks provided by SAP describe basic business activities from an organizational point of view. A single-step task relates to a single object method (= technical link to SAP functionality) in each case, and is linked to its organizationally possible processors.

Object Types (MM-PUR-REQ)

In this scenario, the following business application objects are processed (i.e. a purchase requisition is released or rejected using a release code).

Purchase Requisition for Item-Wise Release
Type BUS2009 (PurchaseReqItem)
Purchase Requisition for Overall Release
Type BUS2105 (PurchaseRequisition)
Location in Object Repository:
Materials management _ Purchasing
Tasks: Release of Requisition (MM-PUR-REQ)
In these tasks, a purchase requisition is released or rejected using a release code.
Item-Wise Release
Task: TS00007986
Identifier: req_rel
Description: Release of purchase requisition
Referenced Object Method, Attributes
Object type: BUS2009 (Purchase requisition)
Method: SingleRelease (individual release)
Attributes: None
Overall Release
Task: TS20000159
Identifier: mm_req_rel_c
Description: Overall release of purchase requisition
Referenced Object Method, Attributes
Object type: BUS2105 (Purchase requisition)
Method: SingleRelease (individual release)
Attributes: None
Maintaining Processor Assignment
At runtime, these tasks are addressed to the processor(s) (processing staff member(s)) to whom
the release code has been assigned via a role resolution. You must make the following settings in Customizing for this:

In Task-Specific Customizing for SAP Business Workflow you must list all organization management objects that are generally permitted to work with workflow-relevant release codes (e.g. jobs or positions).
Prior to this, the organizational plan (defining the organizational structure) must be finalized.
User HUBBARD holds the position Member of Executive Board, and user
SEAGOON the position Sales Manager.

By assigning a release code to a processor in Customizing for Purchasing, you specify who in concrete terms may process a document (i.e. effect releases) using this code. Take care that this assignment is compatible with the processor assignment in Task-Specific Customizing. If you enter a user, for example, the latter must also be the holder of a position in Task-Specific Customizing. If you enter a position, precisely this position must also be defined in Task-Specific Customizing and have users assigned to it.


Release codes EX (Executive Board) and KY (Sales Manager) are assigned to the

object type User and have the processor IDs HUBBARD and SEAGOON assigned to
them respectively.
It is also necessary for the release codes to be marked as “relevant to Workflow”.
See also Preparation and Customizing (MM-PUR-REQ) [Page 33]
Determining the Processor In determining the processor (the person who is to process the document), the system searches the Purchasing Customizing facility for the processor ID for a release code. This is achieved via role resolution.
For this purpose, the following roles are defined for the relevant task:

Item-Wise Release

Role 00000148 (Person responsible for requisition release)

Overall Release

Role 20000026 (Person responsible for requisition release)
Input for the role comprises the release code and the purchase requisition. These were passed on to the role container from the task container.

Role Container Task container requisition <- _WI_OBJECT_ID ReleaseCode <- ReleaseCode Then, using this data, the Customizing settings for Purchasing containing the linkage between release code and processor ID are read.

After this, the system checks whether these settings agree with those of Task-Specific Customizing. If they do not, the workflow terminates and the system administrator responsible for workflow is informed by mail accordingly. In the Customizing facility for Purchasing, user SEAGOON is assigned to the workflow-relevant release code KY as processor.

In addition, in Task-Specific Customizing, SEAGOON is assigned to the position Technical Services. Terminating Events The tasks for releasing complete purchase requisitions or requisition items are terminated by the events Release refused, Release effected, or Requisition significantly changed. Tasks: Release of Requisition Effected (MM-PUR-REQ) via these tasks, the creator of the purchase requisition is informed that release has been effected (approval has been signified).

He or she receives this information via the text of the work item representing the task. The creator processes the work item and thus concludes it. There is no further functionality besides this conclusion of the work item. Item-Wise Release Task: TS00008018 Identifier: req_rel_ok Description: Requisition release effected. Referenced Object Method, Attributes Object type: BUS2009 (Purchase requisition) Method: InfoReleaseEffected (Info: release effected) Attributes: None Overall Release Task: TS20000162 Identifier: mm_req_ok_c Description: Requisition release effected.

Referenced Object Method, Attributes Object type: BUS2105 (Purchase requisition) Method: InfoReleaseEffected (Info: release effected) Attributes: None Maintaining Processor Assignment These tasks should be classified as general tasks. General tasks do not have to be assigned to a processor because anyone may execute them. The processor (= creator of the purchase requisition) is determined from the context of the workflow. Tasks: Release of Requisition Refused (MM-PUR-REQ) Via these tasks, the creator of the purchase requisition is informed that release has been refused. He or she receives this information via the text of the work item representing the task.

When the creator carries out the work item, he or she can change the rejected requisition. Maintaining Processor Assignment These tasks should be classified as general tasks. General tasks do not have to be assigned to a processor because anyone may execute them. The processor (= creator of the purchase requisition) is determined from the context of the workflow.