You are on page 1of 8

Functional Specification

Functional Specification
MM-WF-002
PO Approval Workflow for approved/ rejected
purchase orders

1/8
Functional Specification

Document History

Techincal Specification
Section I: Object General Information
Title (RICEF No): MM-WF-002 Date: 10.05.2012
Short description: PO Approval Workflow for approved/ rejected purchase orders

SAP Module/Team: MM

Functional Contact: Basab Bose

Technical Contact Sourav Roychowdhury

Priority: 1
Complexity Level Very Very 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/8
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/8
Functional Specification

1. Overview and Scope

1.1. Functional Description

Once PO is created Email will be sent to the approver’s SAP inbox with a link of the PO.
After Finally released any Changes made in the PO will reset the PO release strategy apart from
below mentioned fields:
 Down payment Request
 Text in PO

Case 1: PO is pending for approval

Email Subject: PO XXXX is pending for your approval

Body:

PO XXXX is ready for approval. Kindly Approve.


Thanking you,
SAP Workflow

Case 2: PO is finally approved

Email Subject: PO XXXX is finally released.

Body:

PO XXXX is ready for approval. Kindly Approve.


Thanking you,
SAP Workflow

Case 3: PO is rejected.

Email will be sent to Buyer (PO creator).

Email Subject: PO XXXX is rejected

Email Body:

PO XXXX is rejected by approval authority.

Thanking you,
SAP Workflow

4/8
Functional Specification

Case 4: ZMOT PO approval req???

(Move order transfer) value is > 1L , notification will go to HOD based on custom table developed for
DOP mapping .

Email Subject: Transfer order XXXX created for value > 1 L

Email Body:

Transfer order XXXX created for value > 1 L

Thanking you,
SAP Workflow

1.2. Assumptions
N/A

1.3. Transaction Volume


As per Total GRN vol.

1.4. Frequency & Timing


Real Time

1.5. Processing Type


Real Time processing.

1.6. Output Time


Immediately once the output is issued

1.7. Retention Requirements


Not Applicable.

5/8
Functional Specification

1.8. Audience and Distribution


Not Applicable.

2. Detailed Functional Requirements

2.1. Functional Specification for Enhancements

Workflow will trigger when the PO will be created or release strategy is re-set.
Workflow object is BUS2012. Event for :
PO Created is : CREATED
PO Changed: CHANGED
PO Rejected: REJECTION_START
1. It will check the document type. If PO document type is NB WF terminated.
2. For document type =ZMOT, it will check PO value. If PO value is > 1L. It will send the
notification to the HOD as mentioned in Case 4 above.
3. For all other document type check whether EKKO- FRGKX is blank. If Blank then terminate
the WF. Else check the value of EKKO- FRGKX.
4. If EKKO- FRGKX= R (PO Fully released), It will send email to the SAP Inbox with the link to
the PO for release.
A) Find release code: Find out the current level in PO EKKO- FRGZU. It is the count of
alphabet.
B) It will check table T16FW for the user ID OBJID against Release code , Release group &
Plant exists in the PO. Email will be sent as mentioned in Case 2 above.
5. A) If EKKO- FRGKX= B( PO in Release), Find out the current level in PO EKKO- FRGZU. It
is the count of alphabet. Save it in temp field i_polevel.
B) Find the next level required for the PO. Pass Release Group & Release strategy from PO
in T16FS. Find out the value of release code from release code for which technical name
is “Concat (FRGC, i_polevel+1)”.
C) It will check table T16FW for the user ID against Release code , Release group & plant
exists in the PO. Email will be sent as mentioned in Case 1.
6. If PO is rejected. Email will be sent to PO creator with subject as mentioned in Case 3:

If the PO is changed after fully released. The release strategy in PO will reset.
1. It will only work if current PO is fully released EKKO- FRGKX=R & changes not made in PO
Down payment fields and in PO text fields.
2. It will go to CDHDR table will pass the PO no as OBJECTID. Find out the current change no.

6/8
Functional Specification

3. Go to CDPOS for the change number and find if TEXT_CASE=X or Field name is DPAMT,
DPDAT , DPPCT , DPTYP ignore
4. It will call BAPI function module BAPI_PO_RESET_RELEASE.
5. In PO if release Indicator =R , Pass FRGGR & FRGSX from EKKO in T16FS to find out
FRGC1. Pass PO no & FRGC1 in the FM to reset the release strategy.

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

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)

7/8
Functional Specification

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 Results Obtained
Step
No

4. Appendix

4.1. Glossary of Terms

Term Definition

4.2. Additional Reference Documentation

8/8

You might also like