Functional Specification

Functional Specification
MM_WF_001
Notification to user for approved rejected
purchase requisitions

1/12
 Functional Specification

Document History

Techincal Specification
Section I: Object General Information
Title (RICEF No): MMWF001 Date: 25.03.2012
Short description: Notification to user for approved rejected purchase requisitions

SAP Module/Team: MM

Functional Contact: Basab Bose

Technical Contact Sourav Roychowdhury

Priority: 1
Complexity Level High
Program type Workflow

Status InProgress /Finished / Released

Reviewer

Role Name Signature Date

Accenture Consultant Umesha S Guntaga

Approver

Role Name Comments Received Date

2/12
 Functional Specification

Table of Contents

1. Overview and Scope 4

1.1. Functional Description 4
1.2. Assumptions 4
1.3. Transaction Volume 4
1.4. Frequency & Timing 4
1.5. Processing Type 4
1.6. Output Time 4
1.7. Retention Requirements 4
1.8. Audience and Distribution 4

2. Detailed Functional Requirements 5

2.1. Functional Specification for Enhancements 5
2.2. Error Handling 5
2.3. Security and Authorization 5
2.4. Processing and Operational Considerations 5
2.4.1. Performance 5
2.4.2. Batch Requirements 5
2.4.3. Others 6

3. Test Script 6
3.1. Testing Pre-requisite 6
3.2. Test Case 6

4. Appendix 6
4.1. Glossary of Terms 6
4.2. Additional Reference Documentation 6

3/12
 Functional Specification

1. Overview and Scope

1.1. Functional Description

PR Approval Process (Release Strategy)

PR approval proccess will be configured as per DOP in the system for plant wise. It will refelect all
levels present as per DOP for the Value. PR release strategy can accomodate maximum of 8 levels.
Apart from DOP levels other vacent positions can be configured for Concurrance.

Fund Center Mapping:

In PRs fund center will be the identification of Departments. Every PR Creator’s Id will be mapped
with fund center. Fund center will be derived automatically in the PR(for all types like Revenue/
service/ Proj..) via User ID by FM derivation  & Fund centers will be mapped with Departments in a
custom Z table  .

Types of PRs based on Origin:

 Revenue supply: Fund center will be there( PR: Fund center can be the identification of a
department.
 Revenue Service: Fund center needs to be derived from the Cost center.
 CAP/Project Material PR: Fund center needs to be derived from user ID of the PR creator.
With no budget check at commitment.
 CAP/Project Service PR: Fund center needs to be derived from user ID of the PR creator.
With no budget check at commitment.
 Maintenance Order: Fund center will be derived from user ID of the PR creator.

Development of Z table:
Every department may not have the all approving position hiararcy like DGM , GM , AVP, VP and so
on (example from Vijaynagar). To meet up the situation one Custom table will be build up which will
be a link up between Plant ,Department , Positions present in the Departmrnt , People in different
positions (For email notification). This can be used for Vacation rule & Deligation also.

Refer Sheet ZTABLE in the attached document for functionalitiies.

This need to be filled up & Maintained by some authorize person nominated by JSW.

Process Flow:
Once any changes (Created / Change / Release) made in PR which is under release strategy one
work flow will trigger. It will find out the department & Current status of the level from Z table and will
approve for that level if the level is marked as vacant in the Table. It will sent the notification to the
next level (Case 3)

If the level is not Vacant it will send the notification to the user Id maintained for the level. Refer
Case 3 below.

4/12
 Functional Specification

This process will be continued untill the PR is finally released.

If the PR gets rejected during the release process Email will be treiggered to Intender . Refer Case 2
below . In this case teh WF will not search for Designation.

If the PR is finally released it will send email as mentioned in Case 1 below. Once the PR is finally
released no one can edit the PR line items. Buyer will select appropriate blocking reason if there
are some discripencies in the PR. Email will be triggered as mentioned in Case 4 below.

PR workflow email will be triggered at different stages of PR approval processes. Users need to log
in to the system for approving / rejecting / Blocking the PR.

Every user ID will be assigned with Department’s Fund center Authorization group.During PR
approval, system will check the Fund center associated with the PR and the Fund center he/she is
authorized for. Thus it will not be possible for other department to approve other department’s PR.

Email Details:

All emails will be trigged to user’s SAP inbox only.

Different emails will be triggered on different scenarios as mentioned above:

Case 1: If PR is finally released for PO

Email will be triggered to Intender.

Email Subject “PO &EBAN- EBELN created from PR &EBAN- BANFN “

Email Body:

Dear Sir / Madam,

PO &EBAN- EBELN has been created from PR &EBAN- BANFN by &EKKO- ERNAM on
&EKKO- AEDAT.
Please keep in touch with purchaser for further correspondence.

Thanks,
JSW Automated mailing system

Case 2: If PR is rejected

Email will be triggered to Intender.

Email Subject “PR &EBAN- BANFN is Rejected“

Email Body:

Dear Sir / Madam,

PR &EBAN- BANFN has been rejected by &EKKO- ERNAM on &EKKO- AEDAT.
Please keep in touch with the approver for further details.

5/12
 Functional Specification

Thanks,
JSW Automated mailing system

Case 3: If PR is under Release

One Z table will be maintained to find out the next approval levels as per with PR release
strategy. As of now every department will be identified by individual release strategy. If there is
any change in the PR release strategy development , this Z table also will be modified
accordingly by consulting team.

Email will be triggered to next level of approvers

Subject “PR &EBAN- BANFN is pending for your approval“

Email Body:

Dear Sir / Madam,

PR &EBAN- BANFN is now pending for your approval. Please login to SAP and approve with
your SAP ID.

Thanks,
JSW Automated mailing system

Case 4: PR blocked by buyer:

Email will be triggered to the Intender

Subject “PR &EBAN- BANFN is is blocked by Purchasing“

Email Body:

Dear Sir / Madam,

PR &EBAN- BANFN is blocked & unreleased by purchaser.. The reason for blocking is
BLOCKING CODE Description. Please re-approve the PR again.

Thanks,
JSW Automated mailing system

1.2. Assumptions
Maintenance and data upload activity of org structure in Z table will be done solely by JSW /
JSOFT centralize team.

6/12
 Functional Specification

1.3. Transaction Volume

Approximate 1000 emails will be triggered per day across all plants.

1.4. Frequency & Timing

Real time

1.5. Processing Type

Real Time processing.

1.6. Output Time

Not Applicable

1.7. Retention Requirements

Email log can be removed from SOST table for more than 2 months old.

1.8. Audience and Distribution

Not Applicable.

2. Detailed Functional Requirements

2.1. Functional Specification for Enhancements

Workflow will trigger whenever there will be any changes in the below mentioned events for
purchase requisition business object BUS2105.

RELEASESTEPCREATED Requisition Release Step Generated

REJECTED Release of Purchase Requisition Refused
RELEASED Release Purchase Requisition
CREATED Purchase requisition created

All the steps will be in Workflow history.

Step Description:
 Step 1: Get PR document type: EBAN-BSART
 Step 2: Get PR processing status: EBAN-BANPR
 Step 3:

7/12
 Functional Specification

Case 1: EBAN-BANPR=5 If PR is finally released for PO

 Step 4: Get email address of PR creator: EBAN- ERNAM
 Step 7: Send email to PR creator with Subject “PO &EBAN- EBELN created from PR
&EBAN- BANFN “

Email Body:

Dear Sir / Madam,

PO &EBAN- EBELN has been created from PR &EBAN- BANFN by &EKKO- ERNAM on &EKKO-
AEDAT.
Please keep in touch with purchaser for further correspondence.

Thanks,
JSW Automated mailing system

Case 2: EBAN-BANPR =8 If PR is rejected

 Step 5: Get email address of PR creator: EBAN- ERNAM
 Step 8: Send email to PR creator with Subject “PR &EBAN- BANFN is Rejected“

Email Body:

Dear Sir / Madam,

PR &EBAN- BANFN has been rejected by &EKKO- ERNAM on &EKKO- AEDAT.
Please keep in touch with the approver for further details.

Thanks,
JSW Automated mailing system

Case 3: EBAN-BANPR =3, If PR is under Release

 Step 6: One Z table will be maintained to find out the next approval levels as per with PR
release strategy:

Find out the EBAN- FRGZU (Say XX), Count the no of characters (2), It means the PR is released
by 2nd level. Find out the email ID of next level from the Z table for notification sending.
 Step 9: Send email to next level approver with Subject “PR &EBAN- BANFN is pending for
your approval“

Email Body:
Dear Sir / Madam,
PR &EBAN- BANFN is now pending for your approval. Please login to SAP and approve with your
SAP ID.
Thanks,
JSW Automated mailing system

Case 4: PR Blocked and unreleased by buyer

8/12
 Functional Specification

Email will be triggered to the Intender

Subject “PR &EBAN- BANFN is blocked by Purchasing“

Email Body:

Dear Sir / Madam,

PR &EBAN- BANFN is blocked by purchaser. The reason for blocking is BLOCKING CODE
Description. Please re-approve the PR again.

Thanks,
JSW Automated mailing system

Develop a custom work flow in SAP Work flow Builder as per the steps mentioned above.

9/12
 Functional Specification

RELEVANT DOCUMENT SECTION:

Document Description Attachment

Detaild documentattion
PR Release.xlsx

2.2. Error Handling

Not Applicable

2.3. Security and Authorization

Not Applicable

2.4. Processing and Operational Considerations

2.4.1. Performance

Not Applicable

2.4.2. Batch Requirements

Not Applicable

10/12
 Functional Specification

2.4.3. Others

3. Test Script

3.1. Testing Pre-requisite

[Indicate the pre requisite conditions to use to verify successful operations of the conversion.]

Pre-requisite Type Data Element Details

(Master data, Config,
Other Development)
Necessary configurations should be in place for
release procedure.

3.2. Test Case

[Document all scenarios associated with this development. Examples would include testing an error-
free run, testing the exception processes, and testing the error handling.]
<Test Case No.XX>

Test Test Step Description T Code Input Data Expected Results Obtained
Step Results
No
1

2
3

4. Appendix

4.1. Glossary of Terms

Term Definition

11/12
 Functional Specification

4.2. Additional Reference Documentation

Refer MM_WF_001 as a part of same scope.

12/12