Вы находитесь на странице: 1из 14

SE 5.

1 Functional SPECIFICATIONS
RICEFW (Workflow)
WORK ORDER APPROVAL WORKFLOW
W.PM.210.12

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


1
PROJECT IDENTIFICATION

Project Name Project Code


Hilmar Cheese Business Transformation Program –
HILMAR-SAPIMPL-BBPHASE
Business Blueprint phase
Customer Name Customer Number
Hilmar Cheese Company
Wipro Project Manager Customer Project Manager
Amit Jain Carina Hernandez

DOCUMENT IDENTIFICATION

Author Document Location (repository/path/name)


Anil George <Document location>
Version Status Date (YYYY-MM-DD) Document Classification
0.1 Final <Date> Confidential

REVISION HISTORY

Version Date Description

0.1 02.28.2014 Initial Draft


0.2

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


2
REVIEW AND APPROVAL

Name Date (YYYY-MM-DD)


Customer Project Manager

Name Date (YYYY-MM-DD)


Wipro Project Manager

Name Date (YYYY-MM-DD)


Key Stakeholder

Name Date (YYYY-MM-DD)


Key Stakeholder

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


3
Table of Contents

1. How to use the Template...................................................................................................4


2. General Object Overview...................................................................................................5
3. Workflow Specific Design...................................................................................................6
3.1. Current Functionality.........................................................................................................6
3.2. Required Functionality.......................................................................................................6
3.3. Workflow Process Flow Diagram........................................................................................6
3.4. Workflow steps description...............................................................................................6
3.5. Workflow Details...............................................................................................................6
3.6. User Exit/ Workflow Details Description............................................................................7
3.7. Security Requirements and Authorization Details..............................................................7
3.8. Dependencies....................................................................................................................7
4. Assumptions......................................................................................................................8
5. Use Cases..........................................................................................................................8
6. Issues................................................................................................................................8
7. Additional information and attachments...........................................................................9
8. Part B – Additional Details to be filled by Hilmar Cheese IS................................................9
8.1. Custom Screen Design (if any)............................................................................................9
8.2. Custom Tables/ Structured in SAP......................................................................................9
9. Validation and Testing Scenarios......................................................................................10

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


4
1. How to use the Template

This document is intended to specify RICEFW object from a functional perspective. It will be followed by a technical
specification during Realization. A Functional Specification has three main sections with the purpose of describing the
expected behavior of the development object.
 Object information, to be filled in for all RICEFW objects
 Object specific details (Processing, calculations, and business logic for the development object)
 Object specific requirements

This document builds and refers to three preceding documents


 Business Process Design Document – BPD document
 Fit Gap Analysis – FGA
 Requirement Traceability Matrix - RTM

2. General Object Overview

Area (SAP System components) SAP ECC EHP7

Program Transaction code IW31, IW32

Short description Work Order approval workflow

Transaction ID / Demand Number PM.210.12

Priority High / Mandatory Complexity High

General information

What is the approximate duration of


see estimate
development work (in man days)?

Is there an alternative in the standard Yes No


system? If yes, describe the alternative:      

Performance problems Complexity


Why is the alternative not acceptable? Others (Specify): decision has been made by PSC to
required approval for each work order

Reference Document(s) One of the reference is PM_210 Corrective Maintenance

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


5
3. Workflow Specific Design
3.1. Current Functionality
In the current process, work order approval is not a functionality in the system but rather a meeting
agreement to proceed.

3.2. Required Functionality


Decision has been made by PSC that every work order would require an approval base on the approvers
limit before work can be performed. Each approver should receive an email notification from the work flow
asking for approver for review and approval.
This will require a customized workflow with a logic as described below:
1. Workflow would be triggered when user status of a work order is set to "Sent Out for Approval",
and cost approval permit is triggered which blocks work order from being released.
2. Workflow sends to approver. There will be a maximum of four levels of approval required and the
workflow will start from the 1st level approver to the last level approver with appropriate approval
limit.
Note: Approval Authority is to be defined by DoA. (Delegation of Authority).
3. Once all approval obtained, workflow sets work order user status to "Approved", approves
permit. And release the work order.
4. If approval is rejected, work flow sets work order user status to "Approval Rejected" and send
email notification to the initiator of work order with comment from the approver.

3.3. Workflow Process Flow Diagram


Workflow sends out for approval:

Work Order Set Work Order Status Approvers


Workflow Notifies
Initiator to “Sent out for Approval” Approvers Approve or Reject

Approver rejected the work order:

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


6
Approver Workflow Sets Status Work Order
Workflow Notifies
Rejected to “Approval Rejected” Initiator Initiator

3.4. Workflow steps description


Process steps should be descriptive in nature. The aim of the process step is to describe the overall business
process.
Transaction Used: IW31/IW32.
User tables used: TJ30- ESTAT=E000X
Business object used: BUS2007 (maintainance order). New subtype to be created to add new event
‘Rejected’ as the standard has only ‘Created’ event.
Standard Workflow Template available: WS20000014(PMO Maintenance planner). New Workflow template
to be created for the customization.
Steps involved:
1) DoA (Delegation of Authority) to be defined as customized table in the system with below details.
Table maintenance is required. Field validation is required. The Approval levels are to be derived
from the HR Minimaster Organizational Chart, for starting the Development please create and use
the Custom table as shown below:
Table Name: ZHCCSAM
Description: Hilmar Signarture Approval Matrix
Cost Order_typ Approval_Lev Approver_User Approval Currenc
center e el Approver_Name id Limit y
Production
    1 Manager   10,000 USD
    2 Site Director   25,000 USD
    3 Vice President   100, 000 USD
    4 CFO   >100000 USD

2) Workflow must be triggered on activating user status “Sent Out for Approval”.

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


7
3) Workflow to be sent out to 1st level approver for approval according to the cost receiver of the work
order. Cost receiver will be cost center of the equipment or functional location for maintenance
orders and internal order for capital project orders, according to the SAP standard sytem
configuration. Workflow to send email to the initiator for confirmation.
a. Cost to be approved is determined by planned cost or estimated cost of the work order,
whichever is higher.
b. The logic for getting the total plan cost from the order is as follows
Get the CAUFV -OBJNR and pass to PMCO-OBJNR and get the plan cost by adding WRT00+
WRT01+…..+ WRT16 where WRTTP=1. Add all the values if WRT00 repeats. This will be
applicable to WRT01 to WRT16.
c. Approver will be determined from the DoA table by work order type, cost center or internal
order(based on order type, PM01, PM02, PM03, PM05 and PM08 are for cost center, order
with order type PM06 will have the approver selected based on internal order number of
the settlement rule), plant, and authorized spending limit.
d. Workflow email format to be created as below:

Subject: Work Order: "Emergency" approval for # 819747

Body: Dear Approver,

You are receiving this automated email because your approval is required on the below work order:

PM Order Order Description Created Date Total Estimate Requestor


$
819747 Urgent work is required for Vat 1 12/24/2013 2,500.00 Herman R.

Please click on the link below to access and submit your approval response.
If rejected, please provide reasons.

Put the approval link here

Thanks,
From: SAP IS Team

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


8
4) Upon 1st level approval, workflow to be sent out to 2 nd level approver, in case 1st level approver does
not have enough spending limit.
5) Repeat step 4 for next level, until workflow is approved by the approver with enough spending limit.
6) Workflow approved by approver.
a. Workflow to approve cost permit in the work order.
b. Workflow to set work order user status to “Approved”.
c. Workflow to release the work order.
d. Workflow to send email to the initiator for confirmation.
7) In case work order approval rejected, comments need to be filled by approver.
a. Workflow will then set work order user status to “Approval Rejected”.
b. Workflow to send email to the initiator for confirmation.
c. Reject email format attached below:

Subject: Work Order: "Corrective" approval for # 819747 - Rejected

Body: Dear Initiator/Approver,

This is an automated email sent out to inform you the work order has been rejected by an approver.

Work Order Description Rejected By Position Reason

819747 Urgent work is required for Vat 1 Herman Roest Maintenance Manager Can work be done
combine with others…?

To edit this work order, you can log into SAP and use transaction code IW32 to update.

Thanks,
From: SAP IS Team

3.5. Workflow Details

Enter the requested information for each group.

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


9
Mention the start condition for the workflow, e.g. on

Trigger Mechanism creation of a purchase document, batch program etc.

CREATION AND CHANGE OF THE WORK ORDER


Example – The workflow should start only for certain document
type, work flow should start only if credit amount is greater than
Start Condition 250000, etc.
When change the order User status and the values maintained in the
table
Mention the SAP business object, if possible. Otherwise
SAP Business Object indicate the object in general terms (e.g., Purchase Requisition)
BUS2007
In case of enhancement required for SAP delivery workflow is
SAP Standard Workflow Task /
required.
Template N/A

Level of Approval Required One Level Approval

Custom Table - Agents in Custom Table


<use to elaborate on a selection of "Other">
Agent Determination Technique
If the agent determination technique is different for each foreground step then
please repeat this section.

Notification Destination Internal SAP User - SAP Inbox


If any specific work item text/work item subject to be used.
Workflow Notifications Text
N/A
If any deadline monitoring is to be done. Example: If approver
Escalation Handling (if any) does not approve for 3 business days notify his supervisor.
N/A
An exception situation could occur if workflow routes to a one
position is vacant/not available (i.e. no user is assigned to that
position.) If a specific report or additional information is
Error Handling (if any) required. Add attachment if necessary.
Give the error message if the execution is not successful. Error
handling should be taken care during the development.

3.6. User Exit/ Workflow Details Description


If workflow to be triggered from user exit or if any modification required using user exit.

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


10
3.7. Security Requirements and Authorization Details
Enter Authorization objects/ fields to be used and Specific user Groups.

Security Requirements and Authorization Details

<Details on the Security & Authorization>


<Every authorization object needs to be documented to provide the security administrator information on the purpose
and use of the object. The following sections are the minimal documentation requirements.>
User status “Approved” and “Approval Rejected” can only be set by the workflow.

3.8. Dependencies
If there are any dependencies on the workflow process, provide the details.

4. Assumptions
These are a very important part of the specification as they ensure that no unnecessary development work is
undertaken.
It is normal for assumptions to be thought up at the technical development stage as well as the functional
specification stage as development and testing may throw up more obscure scenarios than thought out at a
business level. These should be discussed during the development stage and added to the spec when
agreed.
Example assumptions:
1. All weights in the SAP system will be in pounds (lb).
If no assumptions are taken for this Workflow, indicate “No assumptions taken”.

1. Approval authority will be defined according to the DoA Delegation of Authority.

5. Use Cases

Use case - How the RICEFW object will be used by the user or system

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


11
<A use case is series of steps showing how user will use this object>

Use case 1 Create work order and plan activities, spare


parts etc. Check the plan cost in the order and
change the user status to ‘Scheduled’.

Business process (steps) Test the following scenarios


1. The workflow will trigger to Production Manager
if the plan cost is less than or equal to USD
10,000. Check the mail for the correct recipient.
2. Increase the plan cost by adding more spare
parts and activities.2nd level approval work flow
will trigger to Site Director if the cost is more
than USD 10,000 and <= USD 25,000. Check the
mail for the correct recipient.
3. Increase the plan cost by adding more spare
parts and activities.3rd level approval workflow
will trigger to Vice President if the cost is more
than USD 25,000 and <= USD 100,000. Check the
mail for the correct recipient.
4. Increase the plan cost by adding more spare
parts and activities.4th level approval workflow
will trigger to CFO if the cost is more than USD
100,000. Check the mail for the correct
recipient.

Rules N/A

Solution Approach N/A

Standard(Y/N) N

Enhancement Type (RICEFW) Workflow

6. Issues
This section should be used like a log during the creation of this document to outline any outstanding issues
that need to be resolved prior to continuing with the development work. Prior to sign-off there should be no
open issues remaining.

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


12
Issue Issue Date Issue Description Issue Resolution Resolved By &
# Owner Raised Date
N/A N/A N/A N/A N/A N/A

7. Additional information and attachments


Any information the designer believes to be of benefit to the developer should be attached here. Custom
reports or any other dictionary objects necessary for the correct running of the enhancement should also
appear here.
None

8. Part B – Additional Details to be filled by Hilmar Cheese IS


Fill in any details the designer believes to be of benefit to the developer here.

8.1. Custom Screen Design (if any)


Functional details of custom transaction can be incorporated here. Number of screens required and flow
diagram can be included, provide the selection screen shot along with the table name and field name and
screen shot for the required output.
N/A

8.2. Custom Tables/ Structured in SAP


This section should detail the attributes of any custom table used, and the properties of its fields.
Note: Existing SAP Data Elements and/or Domains should be used whenever possible when creating custom
table fields, in order to avoid unnecessary typos.

N/A
Table Name
N/A
Short text
N/A
Size category
N/A
Table maintenance
allowed
N/A
Data class
N/A
Buffering

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


13
Table maintenance N/A
generation
N/A
Authorization Group

Field Data Domain Type Length Check Key Foreign Description


Name Element Table Field Key
-Field
N/A N/A N/A N/A N/A N/A N/A N/A N/A

Comments
N/A

9. Validation and Testing Scenarios

Validation Requirements

Work order number is verified in the email notification


Initiator and approvers are correctly processed

Test Scenarios
ID Description
Normal Functionality – test cases that ensure the conversion requirement as it should
1 Created a work order and plan with an estimate at each level limits to test the workflow
notifications
2 Change out the higher level approvers after first level is approved
3 Reject the work order at each level and without reasons
4 After rejected, replan and resubmit for approval
Exception - special logic or exceptions
5 N/A
Error Handling - functionality in case of errors
7 N/A

© Hilmar Cheese Company Confidential | 2013 Wipro LTD | www.wipro.com |


14

Вам также может понравиться