Академический Документы
Профессиональный Документы
Культура Документы
Since purchase order is a legal document and it goes to the vendor, it is very much
important to control the process to avoid any errors or unauthorized transaction.
There is a hierarchy of people like the buyer who creates the order and different
levels of purchasing managers to supervise and control the procurement process.
Can be integrated with the email system so that approvers do not have to wait or
enquire about status of particular transactions.
Document Type NB, Purchasing Org 0001, Purchasing Group 001, 002, 003, 004,
005.
Level 4 : > 1,00,000.00 INR – Approver6 (can delegate to any Approver1 / Approver2
/ Approver3 / Approver4 / Approver5)
SAP Easy Access -> Materials Management -> Purchasing -> Purchase Order -> Release
Procedure for Purchase Orders
Business Requirement:
We need to define which fields would be used to determine the release strategy. This
fields constitute the Characteristics in Release Determination. We need to create a
Characteristic for every field.
ZPO_EKGRP – Purchasing Group (001, 002, 003, 004, 005) – Datatype CHAR 3
ZPO_GNETW – Total Net Order Value – Datatype CURR (15, 2) Unit INR
For a full list of fields that can be used to determine the release strategy, use tccode
SE11 communication structure CEKKO.
If we want to make use of a field which is not available in CEKKO, we add that field in
structure CEKKOZZ available within CEKKO, we would need to make use of the user
exit M06E004 -> Changes to communication structure for releasing purchasing
document. The field added in CEKKOZZ should be reflected in Header Data of
transaction code ME21N -> Create Purchase Order.
The characteristics have been grouped together to form the following class –
ZPO_HPPTCL
Note: We can create any new Class assigning it to the relevant Characteristics but the
Class Type should always be 032.
Configuration Path : SPRO -> Purchasing -> Purchase Order -> Release Procedure for
Purchase Orders -> Define Release Procedure for Purchase Orders.
The Workflow Role has been selected as 1 from the dropdown list, since this is related
to workflow release strategy without using a user exit.
0 – Blocked
2 – Released.
Changeable indicator determines how the system would react when a purchasing
requisition or purchasing document is changed after the change of the release
procedure.
1 Cannot be changed
Since we have 4 approval levels, We would create 4 new Release Strategies – R1, R2,
R3, R4.
After configuring the release strategies, the Workflow Role Assignment for the
respective Release Codes needs to be done.
Select Workflow from the Activities Screen. Create Assignment for the agent Codes
W1, W2, W3, W4, W5, W6.
Note: Release Approval can be made position based instead or person by making
reference to the HR Org Structure which would require considerable amount of
customization, has not been covered in this section.
Step 6: Configure the Workflow –
SPRO -> SAP Netweaver -> Application Server -> Business Management -> SAP Business
Workflow -> Maintain Standard Settings
Choose Workflow for Release of Purchase Order (WS20000075) from Workflow Box
Click on Header -> Start Events Tab
Check whether object category BO and Object Type BUS2012 are assigned and is
active.
Go back to initial screen and Activate the workflow builder and Save.
Check whether linkage is activated for object type BUS2012 Receiver type
WS20000075 by clicking on detail button.
Substitution in PO Workflow:
In SAP, the inbox is generally the “SAP inbox” accessed via transaction code SBWP.
SAP also lets you flow the tasks into Lotus Notes and Outlook.
Business Requirement
Substitutes are essential so that a users work items can be seen and executed by a
defined replacement user. This ensures that work is not left unattended if someone is
out of the office unexpectedly.
Active substitution (for eg. for absence due to vacations): In this case, the items
belonging to the absent person are automatically assigned to the substitutes inbox (in
addition to his own work items).
Active substitution is where User A is going on vacation and specifies User B as their
substitute and activates the substitution.
Passive substitution (for example, for absence due to illness): the substitute must
explicitly assume the substitution and will only view the items of the absent person in
this mode.
If Passive substitution is used then the substitute (User B) only sees the work items of
User A. User A sets up the substitution but does not activate it, then User B can Adopt
the substitution if User A is out of the office unexpectedly.
Business Requirement:
In SAP Business Workflow system, there might be multiple Workflows activated at the
same time , e.g. PO Release Approval, HR Time Sheet & Leave Approval, Approval for
QM Notifications and so on. In order to map a substitution rule for a particular Work
Item / Activity, we need to define Task Classes and Classification Profile and make
the relevant assignment.
To define classification labels, go to SPRO -> SAP Netweaver -> Application Server ->
SAP Business Workflow -> Basic Settings -> Maintain Task Classes.
To define substitution profiles, go to SPRO -> SAP Netweaver -> Application Server ->
Business Management -> SAP Business Workflow -> Basis Settings -> Substitute Profile -
> Define Substitute Profile.
A substitution profile defines what tasks a substitute approver sees in his/her inbox
In the previous step, we just defined names for substitution profiles. In this step, we
assign the classifications to the profiles and make their definition complete.
To assign the classifications to profiles, go to SPRO -> SAP Netweaver -> Application
Server – > Business Management -> SAP Business Workflow -> Basic Settings ->
Substitute Profile – > Assign Substitute profile.
The final step, though not technically a customizing activity, is classifying the tasks.
Tasks are classified in transaction code PFTC.
To classify it, go to Additional Data -> Classification -> Create. Drop down on the
classification field and pick one of the available classifications.
Setting up substitutions:
An approver can pick a substitute for a given time period and assign the substitute a
profile.
To pick a substitute from SBWP, go to Settings -> Workflow settings -> Maintain
substitute
Business Requirement:
Offline Approval – when an approver can approve the PO without SAP GUI installed in
his system / outside the office network
Online Approval – when an approver gets a link in his email notification to release a
PO with the help of which he is directed to the SAP transaction to approve the PO.
1. From System Logon – Relevant Approvers can approve the PO from R/3 system
using transaction ME28 for list of releases or ME29N for single release.
The notification also appears in SAP Inbox which can be accessed using transaction
SBWP
2. Directly from email –
Through an SMTP setup, which is generally done by basis, an approver can APPROVE or
REJECT a workflow work item directly from email without logging into SAP. The
approver may not have SAP GUI installed in system.
The list of email IDs to which the workflow items have been sent can be viewed in SAP
through transaction SOST.
SAP Fiori enable you to use your tablet, iPhone or any Android phone to access SAP
applications.
You can view pending purchase orders and approve them using SAP Fiori. If necessary,
you can forward approvals to a different employee for further processing.
Key Features
You can display details for each purchase order, for example, the line items with
detailed information, such as account assignment and conditions.
You can approve or reject purchase orders, and you can forward them to a colleague.
Prerequisites
your system
The Fiori App Details for configuring PO Approval in App based devices can be
obtained from following link.
1. Log on the website link using any browser or configure your Fiori App on your
Android system
3. Scroll down to “Buyer” Section and Click “Approve Purchase Orders” logo
Select the Purchase Order number on Left side to look into details
You can also see the items details such as Price, Discount and any other information.
Approver can also maintains his comments while approving the purchase order and
these comments get maintained in the purchase order header level text
Deadline monitoring defines the time span with in which a job is scheduled to End.
Business Requirement:
If a workflow task (say, approval of the PO) is not executed within the specified time,
Escalation happens. It may be required to inform his/her immediate superior /
colleague regarding the activity if the approver misses on the deadline.
The particular work item is then terminated and the subsequent step (Mail) is
executed.
Configuration:
Use transaction SWDD Workflow WS20000075 -> Go to User Decision step, click on the
Latest End Tab
After selection “Work Item Creation”, choose an offset of 5 minutes. This means that
work item must be executed within 5 minutes of the creation, if not this would
trigger.
Enter recipient details to whom the message to be escalated, if the work item is
not executed within 5 minutes after work item creation.
Use transaction code SWWA to check how the deadline monitoring program is
scheduled in program.
Status Monitoring
Business Requirement:
In order to monitor a PO status at a particular time point, for eg., with which
approver a PO is stuck, or the workflow steps undergone by a particular PO, we need
to run some standard reports which enables Status Monitoring of the Work Items.
Status Monitoring of PO’s awaiting approval can be viewed using transaction SWI6.
Audit Trail:
Business Requirement:
As part of Audit Requirement, one might be interested to see who all are involved in
approving a given PO. It is required to check the SAP User IDs that actually processed
the approval workflow. In order to meet such requirements, there are certain
standard SAP transactions which can be used.
In order to check PO Release History, one can use standard report ME2N
One can also make use of the standard Workflow SWI6, SWIA, etc to check on the
Audit relevant reports (We can search in TSTC table with transaction code SW* in
order to check on the workflow relevant report transactions)
Business Requirement:
Completed notifications are not deleted immediately but are initially assigned the
status Logically Deleted. You can physically delete these notifications from the
database by using an appropriate report. In doing so, you can reduce the size of the
relevant database table. This can result in reduced database-access times.
Furthermore, you can reduce the amount of memory required.
If we execute the report immediately, we can also enter the number of days.
Transaction Code SWWL can also be used to delete Workflows based on their status.
Transaction SWIA can be used to manually complete the workflow instead of deleting
it.
Business Requirement:
For this reason, appropriate authorizations need to be set up in the user profiles
where they user/approver would be given access to the relevant Release
Codeand Release Group only to which they are authorized to.
This is a Basis activity to provide the appropriate Authorization for release codes to
the approvers.
Step 1: Through transaction Code PFCG, create a new authorization group, say,
ZPO_APPROVER1
Step 2: The authorization group should contain the object M_EINK_FRG. The object
needs to be added manually. First, select the object MM_E. Under that, select
M_EINK_FRG.
Step 3: Assign values to the following as per release strategy
Step 4: Use Transaction Code SU01 to provide the rights to the approver as required.
The appropriate Release code and release
I have tried to explain the basic settings for configuring a PO workflow release strategy.
Although the basic workflow configuration may be done by a Functional Consultant, help
of a workflow consultant would be required in order to accommodate more complex
business scenarios. This blog would give you a basic idea on the functionalities we can
perform parallel to configuring the business workflow.
I hope you have enjoyed going through the configuration steps and scenarios. Any
suggestions to this would be highly appreciated.