Processing Credit Memo Requests (SD-SLS-RE)

Purpose

Credit memo requests normally need to be checked by the employee who entered them as well as approved by an additional decision-maker. The value of the credit memo determines who is able to approve it.

Once a credit memo request is created, the system normally creates a billing block. This block prevents you from billing the credit memo request and can only be removed by an authorized employee.

Using the workflow, you can represent the whole business process, with all the people involved, for approving credit memo requests within your company. This enables you to process credit memo requests simply and efficiently. If you do not use the workflow, the system does not control the process flow so you will have to organize the steps in credit memo processing yourself.


If the value of a credit memo request is below a minimum value, the system
automatically releases it for billing by removing the billing block.
If the credit memo request exceeds a certain value, the system automatically informs the employee responsible. She or he receives a work item in their inbox and can process it directly from there.
The employee responsible can cancel, release, or process a credit memo request.
If the employee cancels the request, the system automatically creates a reason for rejection in the credit memo request and ends processing.
If the employee releases the request, the system automatically removes the billing block in the
credit memo request and releases it for billing.
If the employee processes the request, she or he can use all the functions available in the change transaction.
The people informed by the workflow do not need to know either the name of the transaction or the menu path of the transactions involved.

Prerequisites

You have configured the settings in Customizing for the workflow and created an
organizational plan (see Preparation and Customizing (SD-SLS-RE) [Page 17]).

When you create credit memo requests, the system normally sets a billing block, which prevents it from being billed. Only authorized employees may remove this billing block, thus releasing the document for billing. The person who is able to check the credit memo before releasing it depends on the value of the credit memo.
You create the billing block for credit memo requests in Customizing for Sales and
Distribution when you define the order type (Sales and Distribution __Sales __Sales
Documents_ Sales Document Header _ Define sales document types).

When using the workflow for processing credit memo requests, we recommend that you
should only allow the billing block to be removed by the people who are authorized to
release credit memos of any value.


Process Flow

Depending on the value of the credit memo request, the system runs through one of the following processes when you enter a credit memo request:

If the value of the credit memo request is smaller or equal to a certain limit (L1), the system automatically releases the credit memo request. The system removes the
billing block in the background, releasing the credit memo request for billing.
If the value of the credit memo request is between limit L1 and limit L2, or equal to L2, the job responsible is informed that the credit memo request should be checked. All the people assigned to this job receive a work item in their integrated inbox, where they can cancel, release or process the credit memo request.

Cancel credit memo request

The employee has to enter a reason for rejection. The system automatically transfers
the reason for rejection into the credit memo request and stops processing.

Release credit memo request
The system automatically removes the billing block in the credit memo request and
releases the document for billing.

Process credit memo request

Here, the user branches into the “Change sales order” transaction, where they can
use all the functions in this transaction. According to the user’s authorization, he or she can remove a billing block, enter a reason for rejection, or process individual items (for example, delete or add order items, or change the order quantity).

The system checks whether the billing block was removed manually. If there is a
billing block, the system re-checks the value of credit memo request and informs the
employee responsible. This process is repeated until the credit memo request has
either been rejected or released.

Processing Credit Memo Requests

Each employee in the sales department is allowed to release credit memo requests up to a value of USD 300. The following authorization procedure has been defined for credit memo requests that exceed this limit:

Credit memo requests with a value of between USD 300 and USD 5,000 may only be
released by the group leader.

Credit memo requests that exceed a value of USD 5,000, may only be released by the
sales manager.

Object Types (SD-SLS-RE)

The interface between R/3 functionality and the workflow system is created using object technology.

In the following scenario, the business application object for
Credit memo requests is Object type BUS 2094.

Initial Values (SD-SLS-RE)

In the workflow, the person who releases or processes the credit memo request is decided according to the value of the credit memo request. You can determine two limit values: Amount limit 1 and amount limit 2.
In order to ensure correct, cross-company code credit memo processing, you also need to specify a reference currency. The document currency for the credit memo request is then converted into the reference currency.

The following company codes and their house currencies exist in one company:

Company code 1: House currency FRF
Company code 2: House currency DEM

The employees assigned to the sales organization process the credit memo requests
for company code 1 and company code 2.
A reference currency (for example, USD) is defined in the workflow container. The
net values in the sales documents are converted into the reference currency which
means that the credit memo requests can then be processed and checked,
independently of the currency in the company code.


Workflow Template (SD-SLS-RE)

Definition

The following two workflow templates are delivered in the standard system for credit memo processing:

Identification:WS20000009
Identification code: Credit memos
Long text: Credit memo processing

Identification: WS20000019
Identification code:CMR_CHECK
Long text: Check credit memo requests
For additional information, see:
Flow of Workflow Template [Page 14].

Use

Workflow Template 20000009 Credit Memo Processing

Triggering Event in Workflow Template

Updating the credit memo request triggers the event created for object type BUS2094 which starts the workflow template.

Workflow Container and Data Flow

The information needed for the workflow is contained in the credit memo request. This
information is available as an event parameter in the container for the triggered event and have to be transferred into the workflow container using data flow.
The following data flow definition between the triggering event and the workflow container is therefore defined in the standard system:
Workflow Container Event Parameter Container

WF_Initiator <-- _EVT_Object (credit memo request)
RefCurrency (reference currency)
CUSTCOMPLAINTORDER
(credit memo request)
NetValue_Limit_1
(amount limit 1)
NetValue_Limit_2
(amount limit 2)
End_Flag
(End indicator)
The _WF_Initiator element is available in the workflow container in the standard system, while the other elements listed here have been added to the workflow container.

Terminating Events

The workflow template for credit memo requests is terminated with the Release credit memo request and Reject credit memo request events.
Check Workflow Template 20000019 Credit Memo Processing

Workflow Container

The workflow container contains the end indicator (End_Flag), information about the credit memo request (CUSTCOMPLAINTORDER) and the employee responsible (ResponsibleAgents).

Processor Assignment

All people or organizational units that are assigned to the workflow template are informed.

Maintain Processor Assignment

Depending on the net value of the credit memo request and the defined organizational plan, the employee responsible receives a workitem in his or hers integrated inbox.
For this to take place, you must list the various objects from organization management in Customizing for the SAP Business Workflow who can work with workflow-relevant credit memo requests, for example, jobs or positions. Before you do that, you need to set up the organizational plan.

User Haywood has the group leader position while user Miller is in the sales
manager position.
Flow for Workflow Template

When you create a credit memo request, the created event is triggered for object BUS2094 and the workflow template 20000009 is started.
The system checks how high the net value of the credit memo request is. If the net value is below limit 1 (minimum limit), the system automatically releases the credit memo request in background processing.

If the net value of the credit memo request is over limit value 1, the system
terminates workflow

template 20000009 and initiates workflow template 20000019.

The relevant employee, depending on the value of the credit memo request and the
organizational structure in use (sales organization, distribution channel, division), is then informed of this by the arrival of a work item in their integrated inbox. If the employee releases the credit memo request, the system ends the workflow and deletes the work item from the inbox.

If the employee stops processing the work item, it remains in the inbox until it has been completed and only then is the workflow finished.

If the employee changes any of the determining factors in the credit memo request (such as net value), the net value of the credit memo request has to be re-checked. The system deletes the work item from the inbox.

Workflow template 20000009 receives a terminating event and workflow template 20000019 is triggered. Depending on the value of the item, the relevant employee is informed and receives a work item in their integrated inbox. Once the employee has finished processing the work item (by rejecting or releasing the credit memo request), the workflow is concluded. If the credit memo request is changed, workflow template 20000019 is called up. Processing continues until the credit memo request has either been rejected or released.

Terminating Events


The workflow template for checking credit memo requests is terminated with the Release credit memo request and Reject credit memo request events.

Standard Tasks (SD-SLS-RE)

Definition

Standard tasks are single-step tasks supplied by SAP that describe basic business activities.

Preparation and Customizing (SD-SLS-RE)

Activities

Organizational Plan

All the users who have been identified in Customizing for the SAP Business Workflow may release credit memo requests. These users can also be assigned to different organizational units.

Organizational units are areas within a company that belong together for organizational and business purposes, such as a department.

The following organizational units, positions and the people who fill them have been
set up in the system:

Organizational unit Chief position Filled by

Sales organization 0001 Sales manager Miller

Sales area 0001/01/01 Group leader Haywood

You can set up the organizational plan in Customizing for Basis. In the Implementation Guide, choose Basic Components _ Business Management _ SAP Business Workflow _ Edit organizational plan.

Event-Receiver Linkage

The event created for object type BUS2094 (credit memo request) is the triggering event for the workflow template 20000009 and is the standard entry in the event linkage table. In order to start the workflow template, you must activate the linkage between the triggering event and the workflow template, as the receiver for the event, in Customizing for the SAP Business Workflow.


Activate Event-Receiver Linkage

1. Make the settings in Customizing (choose Basic Components _ Business Management

SAP Business Workflow __Perform task-specific Customizing).
2. Activate the event linkage for the workflow template (Sales and distribution

Sales
Activate event linking).

You can also activate the event-linkage by generating workflow template 2000009
directly.
Using and Linking to the Application Functions (SDSLS- RE)

Activities

In the following description, we assume that you have created a credit memo request.
Generating Events The created event that triggers the workflow is created automatically once a credit memo request has been created.

Processing Credit Memos

The people who have been assigned to this task receive a work item in their inbox. If this work item is executed, the credit memo can be released, canceled or processed.
You can call up the inbox by choosing Office __Inbox.

Change Master Contract (SD-SLS-OA)

Purpose

In companies that use a high number of contracts, several contracts are often subject to the same business controls (for example, agreements on pricing or terms of payment). Contracts with the same business requirements can be linked to a master contract as lower level contracts.
The general requirements stipulated in the master contract are then valid for all the lower level contracts assigned to it. The referencing procedure acts as a set of rules in Customizing which enables you to control which data from the lower level contract can be changed and which data has to agree with the master contract. This ensures that the defined requirements remain consistent in all the assigned lower level contracts.

If any of the fields in the master contract that have to be identical to the equivalent fields in the lower level contract are changed, these fields must also be changed in all assigned lower level contracts.

The workflow enables you to control the process of changing master contracts simply and efficiently . All the lower level contracts assigned to a master contract are updated and the employees involved are automatically informed if an error occurs, such as an application error or if the document is blocked.
Process Flow

Changing the master contract triggers a workflow that accesses the assigned lower level contracts and automatically copies the changes to the lower level contract. If an error occurs, a work item appears in the inbox of the person who changed the master contract, who has to process it manually. A separate window displays all the changes that have been made for information purposes.


If a temporary error occurs in a lower level contract that you want to change, for instance, it is blocked because someone is processing it, the system carries out the changes later on in the background. You can decide how much later on the system makes the changes by making the settings for a time span in Customizing. If the system cannot make the changes after several attempts, the person who changed the master contract receives a work item in their integrated inbox. When you trigger the work item, the system tries to change the lower level contract in the background again. If an application error then occurs, the system replaces the work item with a
new one that can only be processed online.

In order to guarantee consistent data retention, all the lower level contracts that are to be changed are blocked until the workflow has finished. Once the changes have been made, the workflow finishes and the document is unblocked.

Using Workflow to Change the Master

Contract

As well as selling office equipment, Miller Ltd also offer their customers an extensive maintenance service. Miller Ltd has signed several maintenance contracts with one of their customers.
The same terms of payment are valid for all the maintenance contracts signed with that customer. These maintenance contracts are assigned to a master contract which contains all terms of payment.

The customer would like to change the terms of payment. The employee responsible at Miller Ltd, Ms. Connelly, changes the terms of payment in the master contract and the changes are automatically copied into all the assigned lower level contracts.
If an error occurs in the system to prevent the changes from being made, Ms. Connelly receives a work item in her integrated inbox for each of the lower level contracts that could not be changed. She can change the lower level contract directly from the inbox using the information displayed in another window about the changes made in the master contract.


If any of the lower level contracts that need to be changed are blocked by another employee, the system carries out the changes in the background. If the document remains blocked, Ms. Connelly receives a work item for that lower level contract in her integrated inbox. Starting the work item causes the system to try and change the lower level contract in the background. The work item stays in Ms. Connelly’s inbox until the changes could be made or an application error occurs. If an application error occurs, Ms. Connelly receives another work item in her integrated inbox that can only be processed online. Once the lower level contract has been changed, the
work item is completed and the document is unblocked.


The lower level contracts that have not yet been updated are blocked for manual processing until the workflow has finished successfully.

Object Types (SD-SLS-OA)

The interface between R/3 functions and the workflow system is created using object technology.

The following scenario explains how:

Master contracts: Object type BUS 2095
Customer contract (lower level contract): Object type BUS 2034
are processed.

Workflow Template (SD-SLS-OA)

The following two workflow templates are delivered in the standard system for changing master contacts:

Identification:WS20000048
Identification code: SD_KK_WF
Long text: Workflow for changing customer contracts
Identification: WS20000049
identification code: SD_GK_WF
Long text: Updates according to master contract
Workflow Template WS20000049

Triggering Event in Workflow Template

When you change the master contract, the changed event for object type BUS 2095 (master contract) is triggered and starts the workflow template. Workflow template WS20000048 starts for all the lower level contracts assigned to the master contract. Workflow template WS20000048 generates a work item for each lower level contract.
Workflow Container and Data Flow Information on object reference for the master contract to be processed (_EVT_OBJECT), the name of the person who changed the master contract (_EVT_CREATOR), a list of all the lower level contracts that should be changed (CONTRACTLIST), and the values that should be changed according to the referencing procedure (CHANGEDVALUES) must be available in the workflow.

This information is available as an event parameter in the container for the triggered event and has to be transferred into the workflow container using data flow.

The following data flow definitions between the triggering event and the workflow container have been defined in the standard system:
Workflow Container Event Parameter Container
GroupContract <-- _EVT_CREATOR
CustomerContracts <-- _EVT_OBJECT
ChangedValues <-- CONTRACTLIST
<-- CHANGEDVALUES

Terminating Events

Workflow template WS20000049 finishes if all the workflows have finished for the lower level contracts (event changed to object type BUS2034). Before this happens, task TS20000233 is triggered (workflow indicator is deleted from table VBAK).


Workflow Template WS20000048 (Change Contract)

Triggering Event

Workflow template WS2000049 triggers workflow template WS2000048 to change all lower level contracts. The workflow template contains the two standard tasks - TS20000140 (change contracts in background processing) and TS20000141 (change contract online).

Workflow Container and Data Flow

The workflow container receives the following information:

CustomerContract
ChangedValues
For the text display of the work item in the employee’s integrated inbox:
msgv4 (MessageVariable 4)
msgv3 (MessageVariable 3)
msgv2 (MessageVariable 2)
msgv1 (MessageVariable 1)
msgtext (short text with replaced variables)
msgno (MessageNo)
msgid (MessageId)
GroupContract

Terminating Events
There is a workflow for each lower level contract which finishes once the lower level contract has been changed (changed event for object type BUS2034).
The complete workflow finishes once all the lower level contracts have been changed.

Standard Tasks (SD-SLS-OA)

Standard tasks are single-step tasks supplied by SAP that describe basic business activities.

The following standard tasks are delivered:
TS20000140
TS20000141
TS20000409
TS20000233

Standard task: TS20000140

Identification code: SD_KK_CHANGE

Description: Change customer contract in the background
Referenced method, attributes Object type: BUS2034 (master contract)
Method: CHANGEINBACKGROUND
Attributes: Background processing
In this task, the system tries to change the lower level contracts, according to the changes in the group contract, in the background. If a temporary error occurs (for example, the document is locked), the system calls up task TS20000409. If this task cannot be implemented because of an application error, the system calls up task TS20000141.

Standard task: TS20000141
Identification code: SD_KK_EDIT
Description: Change customer contract online
Referenced method, attributes
Object type: BUS2034 (master contract)
Method: EDIT (online method)
Attributes: None
If the system could not change the lower level contract in background processing, the person who changed the master contract in task TS20000141 receives a work item in the inbox and can then make the change online.

Maintain Processor Assignment We recommend that you classify TS20000141 as a general task so that the person who changed the master contract is also permitted to process the lower level contracts. If any errors occur, the person who changed the master contract receives a work item in their inbox.

Standard task: TS20000409

Standard Tasks (SD-SLS-OA)
30 April 2001
Identification code: SD_KK_EDIT
Description: Change customer contract in the background (inbox)
Referenced method, attributes
Object type: BUS2034 (master contract)
Method: CHANGEINBACKGROUND
Attributes: Background processing
If a temporary error occurs (for example, the document is blocked), the system will try to change the master contract again in the background at a later point. You can define the time span at which this occurs in Customizing. If the system cannot make the changes, the person who changed the master contract receives a work item in their integrated inbox.

Starting the work item causes the system to try and change the lower level contract in the background. The work item stays in the employee’s inbox until the changes could be made or an application error occurs.
If an application error occurs, task TS200000141 is called up and the person who changed the document receives another work item in their integrated inbox that can only be processed online.

Standard task: TS20000233
Identification code: SD_GK_DQ
Description: Unlock master contract
Referenced method, attributes
Object type: BUS2095 (master contract)
Method: DEQUEUE (synchronous method)
Attributes: Background processing
Once workflow has started, the system automatically sets the ENQUEUE_GRP indicator (block master contract until all lower level contracts have been updated) in table VBAK (sales document header data). Once the whole workflow has finished, the system deselects this indicator using task TS20000233.

Preparation and Customizing (SD-SLS-OA)

Application-Specific Customizing

You need to make the following settings in Customizing for Sales and Distribution:

Update lower level contracts Select the Update lower level contract field for sales document type group contract, so that the workflow copies all the changes in the master contract into the assigned lower level contracts, according to the referencing procedure.

Make this setting by going to Customizing for Sales and Distribution and choosing Sales __Sales Documents __Sales Document Header _ Define sales document types for the
sales document type group contract.

Processor assignment

Assign a processor by going to Customizing for Sales and Distribution and choosing
Sales __Sales Documents __Contracts _ Master Contract __Activate Workflow for
Master Contracts.

Event linkage

You must activate event linkage for object types BUS2095 and BUS2034. You can do
this by going to Customizing for Sales and Distribution and choosing Sales Documents
__Contracts _ Master Contract _ _Activate Workflow for Master Contracts. For more
information on this Customizing activity, see the online Implementation Guide.
Customizing for SAP Business Workflow.


Note that the changes in the lower level contracts are made according to the
referencing procedure for the master contract that was agreed on in Customizing.
See the relevant chapter in the Implementation Guideline for master contracts.
Organizational Plan You can also assign the people who can change the master contract to other organizational units.

Organizational units are areas within a company that belong together for organizational and business purposes, such as a department. However, they are not normally required for the workflow scenario. Only those employees who are authorized to change master contracts and who have changed a master contract, receive a work item in their inbox if an application error occurs, for example, if the workflow is incorrectly implemented. The work item can be forwarded to all the people who are listed in the employee assignment but the employees who process it must also be authorized to change the contracts.


You can set up the organizational plan in Customizing for Basis. In the Implementation Guide, choose Basis Components _ Business Management _ SAP Business Workflow _ Edit organizational plan.

Change customer contract in the background: Set time span
If a temporary error occurs when you change the contract (for example, the lower-level contract is blocked), the system will try to change the master contract again in the background at a later point. You can define the time span at which this occurs in Customizing.

You can define the time span in Customizing for Workflows (Basis Components _ SAP Business Workflow _ Basic Settings (System, SAP Business Workflow) _ Activate automatic monitoring of incorrect work items).


Using and Linking to the Application Functions (SDSLS- OA)

Prerequisites

You have created the link to the workflow (see application-specific Customizing), created a master contract, and assigned the lower level contracts to the master contract.

Process Flow

1. Change a field in the master contract for which there is a rule in the referencing
procedure (Customizing for master contracts).
2. This triggers the changed event for business object BUS2094 (master contracts) and
initiates the workflow template WS20000049.
3. The workflow template WS2000048 is called up for each lower level contract related to the changed master contract.
4. The system implements the standard task TS20000140 (change in background) for all
the lower level contracts:

The system calls up standard task TS20000141 (implement change online) for all
lower level contracts that cannot be changed in the background (change failed event
for object type BUS2094).
The person who changed the master contract receives a work item in their inbox.
The employee can change the lower level contract directly from the inbox using the
information displayed in another window about the changes made in the master
contract. The whole workflow finishes if all the lower level contracts are changed.

The system calls up task TS20000409 (background change of customer contract) for
all lower level contracts that contain a temporary error (blocked by processing).

After a certain time span, which has been defined in Customizing for workflows, the
system tries to change the lower level contracts in the background again. The
workflow is complete once all the lower level contracts have been changed. If the
system cannot change the contract because it is still blocked, for example, the
person who changed the master contract receives a work item in their integrated
inbox.

When they execute the work item, the system changes the lower level
contract in the background. The work item remains in the inbox until the lower level
contract has been changed. If an application error occurs when the system changes
the contract in the background, it calls up task TS20000141. The employee receives
a work item in their integrated inbox that can only be processed online.

Once all the workflows are finished for the lower level contracts, the whole workflow ends.

In order to guarantee consistent data retention, all the lower level contracts that are to be changed are blocked until the relevant workflow has finished for the lower level contract.

Removing Errors in Internet Sales Orders (SD-SLS)

Purpose

In the Internet application component Online Store, customers can obtain quotes and enter orders over the Internet. They can choose to pay either by invoice, credit card or cash on delivery.

If a quotation or order cannot be created because certain master data or Customizing settings are missing or not properly maintained, the transaction is cancelled and an error message is displayed in the customer’s browser.

This workflow enables the relevant associates to be informed automatically about the error so that they can be corrected as quickly as possible.

Process Flow

The event triggering the workflow is generated automatically when an error occurs in the entry of a sales order or quotation in an Online Store.
A work item containing information about the errors that occurred and all the details required to correct the error is sent to the inbox of the sales associates responsible for the Online Store.



Technical Implementation (SD-SLS)

Object Types Used

Object technology is used to create the interface between the R/3 functions and the workflow system. The information given below is of a technical nature and is not necessary for an initial overview.

Standard Tasks

The standard tasks provided by SAP as single steps describe the basic business activities from an organizational point of view. A single-step task relates to a single object method (= technical link to R/3 functionality), and is linked to the agents possible from an organizational point of view.

Workflow Template

The actual operational procedure is implemented as a workflow template. You can find this workflow template in your R/3 system.
Object: Sales Order (SD-SLS)
Definition

The sales order business object (object type BUS2032) is a request from a customer to a company asking for a specific quantity of materials to be delivered, or services to be rendered, on a given date.

A sales order is sent to a sales area, and this sales area is then responsible for fulfilling the contract.

Use

It is also possible to simulate a sales order. In this process, prices are determined, taking account of customer-specific conditions, and current delivery data is determined for a sales order, but the sales order itself is not created. A simulated sales order is referred to as a quotation in this case (not to be confused with the customer quotation business object, object type BUS2031).

Location in object repository: Sales and distribution _ Sales _ Customer quotation
Standard Task TS20000357: Error in Quotation (SD-SLS)

Use

This standard task is used to decide whether an error that occurred during creation of a quotation (in this case, equivalent to the simulation of a sales order in the online store) is to be corrected.

The agent is provided with all information needed to reconstruct and correct the error. This includes the error message plus long text, the online store in which the error occurred, the sales are responsible, the ordering party (customer), all materials in the order items, the pricing date and the delivery date.

The agent can end processing of the task by choosing Error corrected. The agent can also cancel the task, in which case the task remains in the agent’s integrated inbox for further processing.

Object method referenced: object type DECISION, method: Process
Agent assignment: For the validity period, this standard task is addressed to the agents in the sales office or sales area which are responsible for the online store. These employees are determined via standard role 20000045 (agent for Internet sales orders).

Standard Task TS20000347: Error in Order on Account(SD-SLS)

Use

This standard task is used to decide whether an error that occurred during creation of a order for which an invoice is to be issued to the customer is to be corrected. As in standard task TS20000357, the agent is provided with all information needed to reconstruct and correct the error. In addition, the agent is told that the customer wanted the order to go on his/her account and that an invoice was to be issued.

The agent can end processing of the task by choosing Error corrected. The agent can also cancel the task, in which case the task remains in the agent’s integrated inbox for further processing.

Object method referenced: object type DECISION, method: Process
Agent assignment: For the validity period, this standard task is addressed to the agents in the sales office or sales area which are responsible for the online store. These employees are determined via standard role 20000045 (agent for Internet sales orders).


Standard Task TS20000346: Error in Credit Card Order (SD-SLS)

Use

This standard task is used to decide whether an error that occurred during creation of a credit card order is to be corrected. As in standard task TS20000357, the agent is provided with all information needed to reconstruct and correct the error. In addition, the agent is told that the customer wanted to pay by credit card, and is informed of the type of credit card, the card number, and the expiration date.
The agent can end processing of the task by choosing Error corrected. The agent can also cancel the task, in which case the task remains in the agent’s integrated inbox for further processing.

Object method referenced: object type DECISION, method: Process
agent assignment: For the validity period, this standard task is addressed to the agents in the sales office or sales area which are responsible for the online store. These employees are determined via standard role 20000045 (agent for Internet sales orders).

Standard Task TS20000372: Error in Cash-on-Delivery Order (SD-SLS)

Use

This standard task is used to decide whether an error that occurred during creation of a cash-ondelivery order is to be corrected. As in standard task TS20000357, the agent is provided with all information needed to reconstruct and correct the error. In addition, the agent is told that the customer wanted to pay by cash on delivery.
The agent can end processing of the task by choosing Error corrected. The agent can also cancel the task, in which case the task remains in the agent’s integrated inbox for further processing.


Object method referenced: object type DECISION, method: Process,

Agent assignment: For the validity period, this standard task is addressed to the agents in the sales office or sales area which are responsible for the online store. These employees are determined via standard role 20000045 (agent for Internet sales orders).

Standard Role AC2000045: Agent for Internet Sales

Order (SD-SLS)

Use

This standard role determines positions or organizational units that are assigned to a sales office or sales area transferred in a role container.
If this container includes a reference to a sales office (parameter Sales office), the employees responsible for this sales office are determined. If this role resolution leads to no employees being determined, or the container does not contain a sales office (because one is no defined for the online store), the employees responsible for the sales area (parameter SalesAndDistribArea)
are selected.


The structure and assignment of SAP organizational object types Sales office and Sales area to object types of organizational management in Customizing is described later in this document.


Workflow Template: Correcting errors in Internet sales

orders (SD-SLS)

Use

If an error occurs in a sales order or quotation in the IAC “Online Store”, the system starts a workflow based on the template SD_KI_WF.
Workflow template: 20000169, abbreviation: SD_KI_WF, name: Correct errors in Internet sales order Triggering events of the workflow template
The event erroInternetCreate (error creating in the Internet) for object type BUS2032 (sales order) is the triggering event for the workflow template.

This “link” between the event and the workflow template to be triggered is
deactivated in the standard system and must first be activated in Customizing for
SAP Business Workflow, before the workflow template is actually triggered.

Preparation and Customizing (SD-SLS)

Workflow container and binding

As the workflow can only be started if a sales order or quotation is not created because of an error, no object reference to a sales order is available. Event parameter _Evt_Object in the container of the triggering event is initially empty.
The information exists as event parameters in the container of the triggering event and must be transferred to the workflow container via a binding.

As a result, the following binding definition between the triggering event and the
workflow container is defined in the standard system:

Workflow container Event parameter container
MessageType MessageType
MessageID MessageID
MessageNumber MessageNumber
MessageText MessageText
MessageDetail MessageDetail
OnlineStore OnlineStore
OstoreDescription OstoreDescription
SalesDocumentType SalesDocumentType
RequestedDelivDate RequestedDelivDate
PricingDate PricingDate
SalesOffice SalesOffice

SalesAndDistribArea SalesAndDistribArea
OrderingParty OrderingParty
MaterialList MaterialList
SalesOrderSimulate SalesOrderSimulate
PaymentMethod PaymentMethod
PaymentCardType PaymentCardType
CardNumber CardNumber
ExpirationDate ExpirationDate
These elements have been created in addition to the elements available in the standard system.

Preparation and Customizing (SD-SLS)

Use

In addition to the general Customizing procedures that must be performed to make sure workflow system functions properly, several other customizing steps are necessary for this workflow template.

Activities

Processing the organizational structure
Various users are able to check and correct errors in Internet sales orders. These users must be entered in Customizing for SAP Business Workflow. Only those users responsible for handling incorrect Internet sales orders in the sales office or sales areas are to be selected.

First assign a sales order to the online store by choosing Logistics - General _ Logistics Basic Data: Product Catalog _ Internet-application components.
In the container of the triggering event, the sales office and sales area are copied to parameters SalesOffice and SalesAndDistribArea. From here, they are transferred via a binding to the workflow container, and from there to the role container for standard role 20000045 (agent for Internet sales orders), which carries out role resolution in workflow. If this container includes a reference to a sales office, the employees responsible for this sales office are determined. If this role resolution leads to no employees being determined, or the container does not contain a
sales office (because one is not defined for the online store), employees transferred for the sales area are selected.

Enter your organizational plan by choosing Customizing activity Basis Components _ Business Management _ SAP Business Workflow _ Edit organizational plan.
Execute Customizing activity Basis Components _ Business Management _ SAP Business
Workflow _ Basic Settings _ Maintain assignments for SAP organizational object types, and enter the SAP organizational object types Sales office (object type TVBUR) and Sales area (object type BUS0006003), if necessary. List all organizational management object types that are used to correct errors in Internet store orders, such as positions and/or organizational units.

You then use transaction PFOM to assign the appropriate sales office (object type TBVUR) or sales area (object type BUS0006003) to the organizational units and/or positions that represent the sales office or sales area responsible.

Performing task-specific Customizing

Classify the general tasks.

You assign tasks in Sales and Distribution as follows:
1. Execute the Customizing activity (Basis _ Business Management _ SAP Business
Workflow _ Perform task-specific Customizing.
2. Here, under Sales and Distribution _ Sales, choose the activity Assign tasks to agent.
3. Classify the standard tasks TS20000357 (error in quotation), TS20000347 (error in order on account), TS20000346 (error in credit card orders) and TS20000372 (error in cashon- delivery order) as general tasks.
Activating event-receiver linkage
Event ErrorInternetCreate (error creating in Internet) for object type BUS2032 (sales order) is the triggering event for workflow template 20000169 (correct error in Internet sales order) and as such is entered as standard in the event linkage table. So that the workflow template is actually started, you must activate the linkage between the triggering event and the workflow template, as the receiver of the event, in Customizing for SAP Business Workflow.

Activate the workflow template SD_KI_WF in your system as follows:
1. Execute the Customizing activity Basis Component _ Business Management _ SAP
Business Workflow _ Perform task-specific Customizing.
2. Activate the event linkage for the workflow template (Sales and Distribution _ Sales _ Activate event linking).
(Alternatively, you can activate event-receiver linkage by working directly in the workflow template)

Handling of Exceptions at Store Goods Receipt (SDPOS)
Purpose You can use the functions of store goods receipt for stores that donot have a direct link to the central SAP System and therefore post their goods receipt in a store merchandise management system. This goods receipt data is then transferred in the form of an IDoc to the central SAP System, where it is processed automatically. If the data is complete and error-free, the goods receipts of the stores are posted in the central system.

In IDoc inbound processes, exceptions may occur, and you can process these using workflow.

Exceptions are situations in which the system is not able to process data automatically, because information on the goods movement item is missing.
Exceptions therefore usually apply to a single goods movement item. Exception handling is required, for example, if one of the following situations occurs:

The open goods receipt quantity is too low
Quantity variances were determined in the goods receipt check
The system could not uniquely assign a purchase order or delivery to the store goods receipt
The system could not determine a purchase order or delivery to the store goods receipt
The system could not expand a shipping unit into its individual articles

The workflow described below is used to handle these exceptions.

Process Flow

A store associate enters goods receipts and other goods movements in a store's merchandise management system.
As a result, IDocs of type WPUWBW01 are created and used to transfer the information relating to goods receipt to the central SAP System automatically. The central SAP System posts the IDocs in the background.

If one of the above-mentioned exceptions occurs during inbound processing for the IDoc, the system triggers workflow for the item concerned, and creates a work item. The person responsible for processing the exception receives the work item in his/her integrated inbox.

Workflow is complete when no further errors occur for a goods movement item, which means that the data can be successfully posted in the central SAP System.

Technical Implementation (SD-POS)

The following information is of a technical nature. You need the information if you are interested in the details of implementation, or want to carry out enhancements yourself.

Object Types

Object technology is used to create the interface between the SAP functions and the Workflow system.
During POS inbound processing, an IDoc of type WPUWBW01 is created. This contains the data that the central SAP System needs to process the goods receipts that were posted in the store.

The methods for processing work items are provided by business object IDOCPUWB (POS
inbound goods movements). This object type represents the purely technical interface for executing work items, not a concrete IDoc.

Task Group

Task groups are collections of standard tasks, workflow templates and other task groups that are used in a common context.

For this workflow, two technical solutions were implemented that are assigned to the following task groups:

The single-step task for workflow linkage of store goods receipt are grouped together under task group 20000029.

A revised version, in the form of a workflow template (implemented as of Release 4.6) is stored under task group 20000023.
If you want to use this workflow, you must select one of these two solutions in Customizing for POS Interface.

Preparation and Customizing (SD-POS)

Use

Several other specific customizing steps are necessary for this workflow template in addition to the general customizing that is necessary to make sure that the workflow system functions correctly.

Prerequisites

You have carried out the general customizing for SAP Business Workflow.
Customizing Activities for Workflow "Handling Exceptions at Store Goods
Receipt" In the "POS Goods Movements Control " section of Customizing for POS Interface, you define whether you use "old" workflow exception processing (single-step tasks) or "new" workflow exception processing (workflow template), or whether you want to completely deactivate workflow exception processing.

Here, you can also define whether the system handles exceptions for goods receipts for PO items for which the "Delivery complete" indicator has been selected by triggering workflow, or whether the quantity is to be posted directly providing the quantity requirements (such as tolerances) are met.

You choose Workflow _ Store goods receipt to find the Customizing activities generated for old and new workflow exception processing. You can use these Customizing activities to perform task-specific Customizing for both workflow solutions. At this point, you can use the organizational plan to assign the person responsible for processing the exception.

Operation and Link to Application (SD-POS)

Use

When goods receipts are posted in the store, an IDoc of type WPUWBW01 is created.
When the information contained in this IDoc is transferred to the central SAP System, checks are automatically carried out. If exceptions are determined during these checks, the data relating to the goods receipt item(s) concerned is written to the workflow container. This data is transferred to a work item, which is displayed in the integrated inbox of the person responsible for processing the exception. You use the organizational plan to assign the people responsible for processing exceptions.

The methods for processing the work items are provided by business object IDOCPUWB, on which IDoc WPUWBW01 is based.

New Workflow Link (Workflow Template)

In the new version, workflow is executed using a workflow template. This contains the following single-step tasks:

Store goods receipt: Processing step
When the work item is executed, a user dialog is called in a separate window. In this
window, the prepared data for the incorrect goods receipt item is displayed from the
relevant IDoc segment for which workflow was started. An error message relating to the specific problem is also displayed.

Depending on the exception that occurred, the person responsible has various options
for pocessing the item. For example, the person responsible can reject, or post the data, or create an automatic purchase order.
It is possible to process partial quantities of the transferred quantities in sequence. Once a partial quantity has been posted successfully, a new work item is created for the remaining quantity, and you can continue processing with this work item.

Concrete posting of the item is carried out by batch input, which means that the
corrected information is transferred to the central system in the background. If a problem occurs during processing, background processing is terminated so that the person responsible can intervene online at the point where the problem occurred.

Background processing then continues.

Store goods receipt: Delete error log for exception processing
Workflow is complete when there are no remaining quantities to be processed. At this
point, the error log that is displayed in the POS monitor for this POS goods receipt item is deleted.

Old Workflow Link

The old version of workflow is executed with the following single-step tasks:
Store goods receipt for purchase order
Store goods receipt for unknown purchase order
Store goods receipt with automatic purchase order
Operation and Link to Application (SD-POS)

Store goods receipt with quantity variance
Store goods receipt for delivery
Store goods receipt for shipping unit
When the work item is executed, these single-step tasks are run in batch input, with the exception of the single-step task for processing quantity variances. For this step a dialog box is displayed in which the person responsible can correct the quantity variances. Background processing is starts.

All the data determined by the system is transferred to the batch input. If a problem occurs during processing, batch input continues online, so that the person responsible can analyze the problem.

Workflow is complete when the item can be successfully posted.
The error log displayed in the POS monitor for the POS goods receipt item is updated once the work item has been processed successfully.

Releasing a Purchase Requisition (MM-PUR-REQ)

Purpose

Release procedures for purchase requisitions (PReqs) can be used both for individual items and for all the items of a requisition (i.e. for the complete requisition). Such release procedures are necessary, for example, if the requisition exceeds a certain value and authorization is required for the relevant expenditure. It is sensible, for example, to define separate release strategies for different groups of materials for which different departments are responsible, and to define separate release strategies for capital goods and consumption goods.

The document type determines whether the release procedure applies to certain
items only or to the complete requisition.

Release Procedure With/Without Classification

If a complete purchase requisition or a requisition item fulfills certain conditions (e.g. the order value exceeds $10,000), it needs to be approved before it can be converted into a request for quotation (RFQ) or a purchase order (PO). In the SAP System, the release procedure replicates this approval process. Two procedures are available for purchase requisitions:


Release procedure without classification
With this procedure, it is not possible to implement a link to workflow. For this reason, it will not be dealt with here. For more information, refer to the MM Purchasing documentation.

Release procedure with classification
This procedure works with MM Classification, permitting a link to SAP Business
Workflow.
All further information provided here is based on the release procedure with
classification.

Each individual involved in the release procedure signifies approval with his or her release code using a release transaction. Once effected, a release can also be cancelled with the same code (that is to say, the original status is reinstated).
If linkage to SAP Business Workflow has been defined, refusal to release (rejection of a requisition or requisition item) is also possible.

SAP Business Workflow The system can be set up in such a way that a person authorized to release purchase requisitions but whose daily duties primarily involve other tasks is advised via workflow when such a document is awaiting release. That is to say, this person sees a work item in his or her integrated inbox, which can be processed directly from within the inbox. When the item is processed, the release transaction is automatically invoked and the requisition item awaiting release is offered for release or refusal. The individuals who have been informed via workflow that a document is awaiting release thus need to know neither the transaction name (or menu
path) nor their release code.




Releasing a Purchase Requisition (MM-PUR-REQ)

An individual workflow is started for each release step (i.e. for each release code).
IDES A release procedure linked to workflow has been set up in the International Demonstration and Education System (IDES), which you can run through. If you wish to do so, first read the documentation on the demo system (MM Materials Management documentation, section Purchase Requisition - Release Procedure with Workflow and Classification).



Example Scenario for a Release Procedure

All the examples quoted in the following are based on this scenario:
In the Sales and Distribution Department, each employee may prepare and submit purchase requisitions for PCs. Depending on the total order value (and on certain other conditions, see Release Conditions [Page 11]) purchase requisitions are subject to an approval procedure as follows:

Release strategy KF (cost center release)
Requisitions with an order value of up to $10,000 are subject to the following procedure:

irst, a member of the Technical Services Department must check the configuration of
the PCs. Different members of Technical Services are responsible for checking,
depending on the purpose for which the PC is to be used (e.g. for scientific or
administrative purposes). At this point, an alternative release is possible, i.e. only one of the staff members need release the requisition item.

After this, the Sales Manager must approve the requisition, since it is the latter’s cost center that will be charged.
Release strategy TF (technical release)
If the order value exceeds $10,000, the release procedure is basically the same as in the case of requisitions whose total value does not exceed $10,000. However, a member of the Executive Board is additionally required to signify approval (effect release).
Since, as a rule, Sales Managers and Executive Board members are seldom required to approve purchase requisitions, they are informed via Workflow when a requisition is awaiting release.

Release Conditions

Definition

The release conditions determine the release strategy in accordance with which a complete purchase requisition or a requisition item is to be released. The conditions are formulated via characteristic values and are stored in the Purchasing Customizing facility (under the release strategy).
A prerequisite for this is that the characteristics have previously been created in the classification system. For more information on this topic, refer to CA Characte [Ext.]ristics and CA Classification System [Ext.] and the Implementation Guide (IMG) for Purchasing.

To enable a release strategy to be assigned to it, a complete purchase requisition or a requisition item must have one of the possible values for each characteristic.
Release conditions for release strategy KF:



In plant 1000, the preliminary account assignment specified for a purchase
requisition item covering two PCs (material number R-1003, material group 002) is
Asset no. 3221. The total value amounts to $4,920. Purchasing group 001 is
responsible for ordering this item, to which the system automatically assigns the
release strategy KF.


Release Conditions

If a complete requisition or requisition item does not fulfill any of the conditions for a release strategy, it is automatically released for the issue of an RFQ or a PO.

Release Strategy

Definition

The release strategy defines the approval process for purchase requisitions. The strategy specifies the release codes with which a complete purchase requisition or a requisition item must be released (approved) and the sequence in which approvals have to be given. You can assign a maximum of eight release codes to the release strategy.
The assignment of the release strategy to a complete purchase requisition or a requisition item is based on the release conditions.


If the release strategy assignment process is carried out on an item-by-item basis, a
single purchase requisition can contain items with different strategies. The individual items can thus be released separately for the issue of RFQs or POs.
Release strategies KF and TF have been defined.

Release Code

The release code (denoting a release point) is a two-character ID allowing a person to process a requisition item. The release codes are defined in the Customizing facility of Purchasing and assigned to the release strategy. Who may work with which release codes is basically controlled via a system of authorizations (authorization object M_EINK_FRG).

The assignment of a release codes to processors (processing staff members) can additionally be defined as follows:

Organizationally

In this case, the relevant department stipulates which users will be working with which release codes..
With organizational release codes, a purchase requisition item can be released or the
release cancelled.

In Customizing
In this case, there must be a linkage with SAP Business Workflow. You must define the
release codes for which Workflow is to automatically determine the responsible
processor. These release codes are designated as workflow-relevant. A processor ID is
assigned to the workflow-relevant release codes. The processor assignment can be
carried out directly or indirectly:

Directly
The processor is a user name.

Indirectly

The processor ID is a job or a position, for example. At the runtime, the system then
determines the responsible processing staff member.
Jobs are general work areas within an enterprise that are described by tasks (e.g.
Executive Board).
Positions are to be understood as planned employees and can, for example, be
held by a user. E.g. position of Sales Manager (held by user SEAGOON).
With workflow-relevant release codes, refusal is possible in addition to release and
cancellation of release.
An individual release strategy can comprise both organizational and workflow-relevant release codes.
The organizational release codes T1 and T2 (Technical Services) and the workflow relevant release codes KY (Sales Manager) and EX (Executive Board) have been
defined.

Release Prerequisites

Definition

The release prerequisites indicate the sequence in which a complete purchase requisition or requisition item must be approved via the release codes. The release prerequisites are defined in Customizing for Purchasing (in the release strategy).
Release strategy KF (purchase orders up to $10,000)

With the two-step release strategy KF, release by either T1 or T2 is the prerequisite
for release with KY. That is to say, a member of the Technical Services staff (T1 or
T2) must release the requisition item before the more senior level of Sales Manager
(KY).

Release strategy TF (purchase orders above $10,000)
Release strategy TF basically corresponds to the strategy KF. However, the
requisition item must additionally be released by a member of the Executive Board
(release code EX). A prerequisite for release by EX is release by the Sales Manager
(release code KY).

Release Indicator

When a complete requisition or a requisition item has been processed via a release code, a release indicator is assigned to it. The latter shows whether:

The requisition can be changed by materials planning and control

An RFQ referencing the item can be created
A PO referencing the item can be issued
Purchasing can change the quantity or the delivery date
The item can be changed subsequent to the start of the release procedure
You define when the system sets which release indicator in Customizing for Purchasing under "Set Up Procedure with Classification".
Release indicators for strategy KF:

An RFQ or a PO referencing the requisition item can be created if releases have
been effected by T1 or T2 and then with KY.
Release indicators for strategy TF:

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.

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) [Page 24] 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”.

Defining the Organizational Structure (MM-PUR-REQ)

A purchase requisition can be released by various users, who must all be identified in Customizing for SAP Business Workflow. They can also be assigned to various organizational units. Organizational units are a means of subdividing an enterprise according to various business criteria (for example, most enterprises are made up of different departments).

The following organizational units, positions, and holders of the positions have been
defined.

Org. unit Position Position holder
Production and Sales, USA Sales manager SEAGOON
Executive Board, USA Board member HUBBARD
Define your organizational structure via the Customizing activity (Basis Components _
Business-Management _ SAP Business Workflow) _ Edit Organizational Plan.


Performing Task-Specific Customizing (MM-PUR-REQ)

Here you list all organization management objects that are generally allowed to effect releases with workflow-relevant release codes (e.g. jobs or positions) and classify the general tasks.

The task TS00007986 (Release Purchase Requisition) is linked with the positions
Sales Manager and Board Member.
The tasks TS00008014 (Release of Requisition Refused) and TS00008018
(Requisition Release Effected) are classified as general tasks.

Procedure

1. Perform the customizing activity (Basis _ Business Management _ SAP Business
Workflow _ Perform Task-Specific Customizing).
2. Then, under Materials Management _ Purchasing, choose the activity Assign Tasks to
Agent (Processor).
3. Assign the tasks Release Purchase Requisition to the processors (“agents”) who release requisitions via workflow in your enterprise (via Agent Assignment _ Create).
4. Classify the tasks Requisition Release Refused, and Requisition Release Effected as general tasks via Edit _ Attributes.

Activating Event-Receiver Linkage (MM-PUR-REQ)

The event ReleaseStepCreated for the relevant object types is the triggering event for the workflow and is entered in the event linkage table as such in the standard system. For the workflow to actually be started, the linkage between the triggering event and the workflow as receiver of the event must be activated in Customizing for SAP Business Workflow.

Procedure

1. Perform the customizing activity (Basis _ Business Management _ SAP Business
Workflow _ Perform Task-Specific Customizing).
2. Activate event linkage for the workflow (Materials Management _ Purchasing _
Purchase Requisitions _ Activate Event Linkage).
(Alternatively, you can activate event-receiver linkage by processing the workflow directly.)

Application-Specific Customizing (MM-PUR-REQ)

In Customizing for Purchasing, you define:
Which release codes are relevant to workflow
Who may effect release with which code. This assignment is plant-dependent. You have the option of defining either a direct or an indirect user assignment:
Direct

You enter a user name directly.

Indirect

You enter a job or a position, for example. At runtime, the system then determines
the processing staff member responsible.
Take care to ensure that this assignment is compatible with the processor assignment in Task-Specific Customizing for SAP Business Workflow. 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.
You can implement an enhancement (user exit M06B0001) for a release code if you
wish to have a different role resolution than the one defined in the standard system.

The release codes EX and KY are workflow-relevant.
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.
You make these settings via the Customizing activity (Purchasing _ Purchase Requisition _ Release Procedure _) Procedure with Classification. For more detailed information, refer to the Implementation Guide (IMG).

Operation/Link to Appl. Functionality (MM-PUR-REQ)
The following description is based on the assumption that a purchase requisition is created that is subject to the release strategy KF.

Create Purchase Requisition

A user creates a purchase requisition via Logistics _ Materials management _ Purchasing _ Requisition _ Create. This requisition fulfills the conditions of release strategy KF. Saving results in the creation of an object of the type Purchase requisition.

Working Through the Release Strategy T1

The requisition item must be released via the release codes T1 or T2 and then with KY. The users who effect release with release codes T1 or T2 can process the requisition item via Logistics _ Materials management _ Purchasing _ Purchase requisition __Release _ Individual release, for example.

Generate event The workflow-triggering event ReleaseStepCreated is created automatically once release has been effected with release code T1 or T2.
In the event parameter container, you will find the user name of the requisition creator (in the element _EVT_Creator), the reference to the purchase requisition (in the element _EVT_Object) and the release code KY (in the element ReleaseCode).
Release requisition item The user to whom release code KY and the position Sales Manager has been assigned (SEAGOON), finds a work item representing the standard task Release purchase requisition in his SAP Business Workplace inbox. Processing this work item makes possible the release or refusal of the requisition item.
You can access the SAP Business Workplace via Menu _ Business Workplace.


Releasing External Purchasing Docs. (MM-PUR-GF)

Purpose

Release procedures are necessary, for example, if an external purchasing document exceeds a certain value and is subject to approval by a person’s superiors. It is advisable to define different release strategies for certain order types, purchasing organizations, or purchasing groups.

Each individual involved in the release procedure signifies approval with his or her release code using a release transaction. Once effected, a release can also be cancelled with the same code (that is to say, the original status is reinstated).
The system can be set up in such a way that a person authorized to release purchase
requisitions but whose daily duties primarily involve other tasks is advised via workflow when such a document is awaiting release. That is to say, this person sees a work item in his or her SAP Business Workplace inbox, which can be processed directly from within the inbox. When the item is processed, the release transaction is automatically invoked and the document awaiting approval is offered for release. The individuals who have been informed via workflow that a document is awaiting release thus need to know neither the transaction name (or menu path) nor
their release code.
An individual workflow is started for each release step (i.e. for each release code).


Technical Realization (MM-PUR-GF)

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.
Object Types: Release (MM-PUR-GF) '

Tasks

The tasks provided by SAP as single-step tasks 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.

Maintaining Processor Assignment

At runtime, the relevant task is 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.

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.
It is also necessary for the release codes to be marked as “relevant to Workflow”.

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:

Request for Quotation (RFQ)
Role 20000030 (Person responsible for releasing RFQ)
Purchase Order (PO)
Role 20000027 (Person responsible for releasing PO)
Scheduling Agreement
Role 20000028 (Person responsible for releasing scheduling agreement)
Contract
Role 20000029 (Person responsible for releasing contract)
Input for the role comprises the release code and the relevant document. These were passed on to the role container from the task container.
Tasks: Release (MM-PUR-GF)

<- _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. Terminating Events The standard task Release is terminated by the events Release effected, or
significantly changed.

Tasks: Release Effected (MM-PUR-GF)
Via these tasks, the creator of the document 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.

Request for Quotation (RFQ)

Task: TS20000177
Identifier: mm_qr_ok
Description: Release of RFQ effected
Referenced Object Method, Attributes
Object type: BUS2010 (RFQ)
Method: InfoReleaseEffected (Info: release effected)
Attributes: None
Purchase Order (PO)
Task: TS20000168
Identifier: mm_po_ok
Description: Release of PO effected
Referenced Object Method, Attributes
Object type: BUS2012 (PO)
Method: InfoReleaseEffected (Info: release effected)
Attributes: None
Scheduling Agreement
Task: TS20000171
Identifier: mm_pa_ok
Description: Release of scheduling agreement effected
Referenced Object Method, Attributes
Object type: BUS2013 (Scheduling agreement)
Method: InfoReleaseEffected (Info: release effected)
Attributes: None
Contract
Task: TS20000174
Identifier: mm_pc_ok


Tasks: Release Effected (MM-PUR-GF)

Description: Release of contract effected

Referenced Object Method, Attributes
Object type: BUS2014 (Contract)
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 document) is determined from the context of the workflow.


Workflow: Release of Purchasing Documents (MM-PURGF)

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.

Request for Quotation (RFQ)

Workflow: 20000080
Identifier: wf_qr_rel
Description: Workflow for release of RFQ
Purchase Order (PO)
Workflow: 20000075
Identifier: wf_po_rel
Description: Workflow for release of purchase order
Scheduling Agreement
Workflow: 20000078
Identifier: wf_pa_rel
Description: Workflow for release of scheduling agreement
Contract
Workflow: 20000079
Identifier: wf_pc_rel
Description: Workflow for release of contract
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 object reference to the document to be processed (_EVT_Object) and the release code (ReleaseCode), as well as the name of the person who the created the document Workflow: Release of Purchasing Documents (MM-PUR-GF)
(_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
Initiator <- _Evt_Creator <- _Evt_Object Release code <- ReleaseCode In the standard system, the element Initiator exists in the workflow container. The elements and ReleaseCode have been created in addition to the standard elements that exist.