Software Requirement Specification: Budget & Procurement Automation

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 38

SOFTWARE REQUIREMENT Budget &

SPECIFICATION
Procurement Automation

Confidential
January 14, 2016

Page 1 of 38
Confidentiality
© All rights reserved.

No part of this document may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, recording, photocopying or otherwise outside of CMS IT
Services Private Ltd. (Here after referred as CMS) without the prior permission of CMS.

Point of Contact for this document

Name Shivmurthy Sugur

Title Technical Lead

Email Shivmurthy.sugur@cmsitservices.com

CMS IT SERVICES PRIVATE LIMITED, Venkatadri building,


Address
Electronic City Phase I, Bangalore.

Phone D: +91 80 30430302 | M: +91 7259499009

Fax

Page 2 of 38
Table of Contents
1 INTRODUCTION 6
1.1 SCOPE ..............................................................................................................................................................6
1.2 REPORTS .........................................................................................................................................................10
1.3 INTEGRATION ...................................................................................................................................................11
1.4 REFERENCES ....................................................................................................................................................11
1.5 ACRONYMS & DEFINITIONS ................................................................................................................................11
2 FEATURES 12
2.1 DEPARTMENT HEAD ..........................................................................................................................................12
2.2 FUNCTIONAL MANAGER .....................................................................................................................................12
2.3 CFO...............................................................................................................................................................12
2.4 PROCUREMENT USER ........................................................................................................................................12
2.5 MANAGEMENT USER.........................................................................................................................................13
3 USE CASE DESCRIPTION 14
3.1 Portal Login 14
3.2 Add Project 14
3.3 Add Activity 15
3.4 BUDGET ..........................................................................................................................................................16
3.4.1 Budget Opening 16
3.4.2 Budget Request 17
3.4.3 Approve/Reject/clarification Request 18
3.4.4 Clarification 19
3.4.5 Re-open Request 20
3.5 PROCUREMENT ................................................................................................................................................21
3.5.1 Procurement 21
3.5.2 Request for indent 22
3.5.3 Recurring/Renewal for indent 23
3.5.4 Service Available/ Reimbursement indent 24
4 WORKFLOW 26
4.1 NEW INDENT ................................................................................................................................................27
4.2 RENEWAL / RECURRING INDENT ..................................................................................................................28
5 SAMPLE SCREEN SHOTS 31
7 NON FUNCTIONAL REQUIREMENTS 36
8 ASSUMPTIONS/DEPENDENCIES 37
8.1 ASSUMPTIONS..................................................................................................................................................37
8.2 DEPENDENCIES .................................................................................................................................................37
9 ACCEPTANCE CRITERIA 38
Page 3 of 38
Page 4 of 38
Revision History

SR. No. Author Date Version Change Description of PCR No.


Reference Change
1 Lavanya 31-Dec-2015 V.0.0.0
2 Shivmurthy 04-Jan-2016 V.0.0.1
3 Lavanya 05-Jan-2016 V.0.0.2
4 Lavanya 12-Jan-2016 V.0.0.3
5 Anup Kumar 13-Jan-2016 V.0.0.3
6 Shivmurthy 13-Jan-2016 V.0.0.4
7 Lavanya 13-Jan-2016 V.0.0.5
8 Shivmurthy 14-Jan-2016 V.0.0.6

Reviewers

SR. No. Name Version Approved Position Date Signature


1 Ramesh Painuli V.0.0.6 Approver 1 14-Jan-2016
2 Anup Kumar V.0.0.6 Approver 2 14-Jan-2016

Distribution List

SR. No. Name Position

Page 5 of 38
1 Introduction
The objective of this system requirements specification (SRS) document is to capture the functional and
non-functional requirements for the Tally solution Budget and procurement application Portal
implementation project. The System Requirements Specification is the complete list of the system
requirements for the project and as such it is a key project artefact and shall be used during the Design,
Construction, and rollout phases of this project. This document also outlines the high level details of the
existing architecture as understood during the requirements collection phase.

1.1 Scope

Intranet and mobile compatible web based application system for automating the budget and
procurement module, the overall application is divided into two process
 Budget
o CFO will enter the budget guidelines details and amount for each department for the
financial year.
o Department Head receives mail alert from system with budget starting and ending date
along with circular. As per configuration in the system by the admin.
o Department Head or user with appropriate rights will click on budget request option,
user will be guide with the guideline entered from CFO for his department.
o Department Head then click for initiation were user will enter the budget for below
format.

o User has following option


 Submit -> When user clicks on submit the data and request is moved to CFO and
mail triggered to requestor and CFO as per initiate mail template status of
budget request is changed to initiation.
 Draft -> when user clicks on draft, the data is saved in the system and status of
the request is as Draft.
 Cancel -> when user clicks on cancel, page is redirected to home page.
o New task is generated for the CFO

Page 6 of 38
o CFO Logins into the system under the task new item is allocated, below are the action
are available to the CFO.
 Approve -> Budget is approved and mail is triggered to the initiated user and
CFO and status of the request is changed to approved.
 Reject -> Budget request gets rejected with remarks and mail triggered is sent to
the requested user and CFO and status of the request is changed to reject.
Note: - re-open request can’t be rejected in the system.
 Clarification-> User enter the remarks submits a mail triggered and sent to the
requested user and CFO and status of the request is changed to clarification
 Cancel-> User is redirected to home page.
o For requested user task is updated to below status as per the action taken by CFO.
Please find below action for the status updated by CFO.
 Approve -> user can view but can’t modify and it moved from the task list.
 Clarification -> user need to modify the request as per the remarks entered by
CFO status is changed to initiation.
 Reject -> User can view details and need to raise a new request for their
department.
o CFO can re-open approved project based on discussion happened outside the system.
o Task is generated for the requested user and user submits the modified request as per
remarks system validate the amount with respect to budget utilized and queued for the
respective request.
o CFO can approve or ask for clarification but can’t reject the request.
o On the closer of financial year all the request status is closed and system will not allow
any modification for the request with respect that financial year.
 Procurement

In procurement process tally as divide the process into main three category as per there current
process.
o Request
o Recurring/Renewal
o Service Availed/Reimbursement
 Request for indent
o User with appropriate right will log into the system and raise a request for indent for his
department.
o In Request for indent user will select the project, activity, budget and quarter for indent.
o Mail is triggered for the requestor and Functional head
o Task is generated for the department Function head
o Functional head user logins into the portal and view the details. User can reject or
approve the request.
o On user reject the request gets closed and workflow is close.

Page 7 of 38
o On user approve based on amount and configurable workflow amount it moves to CFO
bucket or procurement bucket.
o If request is in CFO bucket mail is triggered for CFO, Functional head, procurement user
and requested user.
o CFO user logins into the portal and click on view of the request from task list, user can
approve, reject and pass the request to management for approval.
o On Approval it goes to procurement team.
o On Reject the request gets closed.
o On seeking the approval from management the request generates task for the
management and mail is triggered to following user.
 Requested user
 Functional head
 CFO
 Management
o On approval from Functional head, CFO and management when the request is
processed to Procurement team.
o Procurement Team will EDIT the form by filling the vendor details and submits for
review to the functional head.
o If there are any discrepancies then Procurement Team will submit for resubmission to
the Functional Head.
o Once the Functional Head Reviews and approves, it moves to Procurement Team
o Procurement user login into the portal and below are the actionable.
 Post Action -> on Post click the system will generate the xml file for the request
and integrate with tally application.
 Update the status of the request to different level.
 Payment -> on payment the request get closed from the workflow and moved
to completed request.
o Indent amount get deducted from the budget once the request is approve from the
system.
 Renewal/Recurring for Indent
o User with appropriate rights will request for the indent, based on the requestor
approval limit the request is updated to the Functional manager or Procurement team.
o In recurring procurement type option for the documents to upload should be enabled
o Pdf and image file can be uploaded with the file size less than 2mb.
o Request for recurring user fills the details and uploads the respective documents and
submits the request.
o Mail is triggered to the functional manager, requestor and the procurement user.

Page 8 of 38
o FM tasks, FM logins into the portal and below action is taken
 Approve
 Request is moved to procurement bucket and task is generated for the
procurement.
 Reject
 Request is terminated with the status as rejected and mail is triggered
to the requestor with the reason.
 Ask approval from CFO
 Request is moved to CFO Bucket and a task is generated for the CFO
o CFO Logins into the portal below are the action that are available for the CFO
 Approve
 Request is moved to procurement bucket and task is generated for the
procurement.
 Reject
 Request is terminated with the status as rejected
 Management Approve
 Request is moved to management task a mail is generated to CFO,
Management users, and FM.
o Management user logins into portal below are the actions that are available for the
user.
 Approve
 Request is moved to procurement bucket and task is generated for the
procurement.
 Reject
 Request is terminated with the status as rejected
o Procurement user logins into portal below are the actions that are available for the
user
 Post
 Request data is pushed to tally system for generating of invoice for the
request.
 Change the Status
 Procurement user will update the status of the request manual for the
activity that are taking offline.
 Close
 Once the all actions are completed user will close the request manually.

Page 9 of 38
 Service Available/ Reimbursement indent

o User with appropriate rights will request for the service availed request and submits the
details.
o In service availed type option for uploading the document is enabled.
o Pdf and image file can be uploaded with size less than 2mb.
o Mail is triggered to the functional manager, requester and the procurement user.
o FM tasks, FM logins into the portal and below action is taken
o Approve
 Request is moved to CFO bucket and task is generated for the CFO.
o Reject
 Request is terminated with the status as rejected and mail is triggered to
the requestor with the reason.
o CFO Logins into the portal below are the action that are available for the CFO
o Approve
 Request is closed and amount is deducted from budget.
o Reject
 Request is terminated with the status as rejected
o Management Approve
 Request is moved to management task a mail is generated to CFO,
Management users, and FM.
o Management user logins into portal below are the actions that are available for the user.
o Approve
 Request is closed and amount is deducted from budget
o Reject
 Request is terminated with the status as rejected.

1.2 Reports

Reports are basically classified into budget and procurement.


 Budget

o Report should be available for all functional heads to view the Budgeted amount for the
quarter, Actuals and the remaining amount.
o Every quarter beginning there should be an option for Functional heads to carry forward
un-used Budgeted amount. This option will not be available for next financial year.
 Procurement

o Month/Quarter wise Summary –


 Which provides information on Department wise Indent created, Value of
Indent, Number of PO generated with Value, Budget amount for that quarter,
Actuals and pending amount.
 On Drill down it should display Indent details.
Page 10 of 38
o Activity wise details –
 Report should be available to view Department wise, Activity wise Budget
amount, Actual amount and Remaining budget
 Drill down on actuals should display Indent/PO details

1.3 Integration

Budget and Procurement solution will integrate with tally application through REST API, REST
API will be developed by Tally and it will be consumed in BPS.
Totally there will be three REST API for integration.
 Master Data Pull REST API
 Procurement indent Push REST API
 Invoice details Pull RESET API

1.4 References

 Requirement Documents
 E-mail Conversations,
 Telephonic Conversations,
 Meetings and Discussions.

1.5 Acronyms & Definitions

This table gives the definitions of key terms used in this document
No Term Definition
1 SRS Software Requirements Specification

2 CIO Chief Information Officer

3 CFO Chief Finance Officer

4 DH Department Head

5 FM Functional manager

6 BPS Budget & Procurement Solution

Page 11 of 38
2 Features

2.1 Department Head

Following are the main features for a Department Head:


 Apply for Budget initiation
 Department Head can submit request for CFO approval
 Save request as draft or cancel the request
 Provide clarification on Budget request when CFO required
 Provision to re-submit the request to CFO
 Request to re-open Budget for modification which already closed
 Can’t modify request once its approved

2.2 Functional Manager

 FM can Approve/Reject the Budget request


 Provision to Approve/Reject the request for procurement
 Can ask approval from CFO
 Approve/Reject the service available request
 Approve/Reject the Recurring request
 Can view the top 5 activities of departments

2.3 CFO

 Opens Budget for financial year with guidelines and amount for each Department
 Provision to open the task generated for CFO
 Provision to Approve/reject/clarification/cancel the Budget request
 CFO can re-open approved project based on discussion happened outside the system
 Provision to give clarification to CIO if required
 Provision to Approve/reject the procurement request
 Provision to view budget details of last 5 years and top activities among all departments

2.4 Procurement User

 Raise a request for indent for his department.


 Provides the details for indent request.
 Recurring the procurement
 Provision to Service available
 procurement user will update the status

Page 12 of 38
2.5 Management User

 Provision to Approve/Reject the Budget


 Provision to Approve/Reject the Procurement request
 Approve/Reject the Recurring Procurement
 Approve/Reject the Service Available for procurement
 Provision to view budget details of last 5 years and top activities among all departments

Page 13 of 38
3 Use Case Description

3.1 Portal Login

Use Case Name: Portal Login

Actors: All users

Description: This functionality to user login to home page and view the Budget
dashboard

Pre-conditions: All the users should have login credentials

Post conditions: Budget details will be displayed based on user rights


 (Mandatory) Login credentials
Input:
 (Mandatory) Masters been created
M – Mandatory  (Mandatory)

 DH User can view the top 5 activities of their department, FM can


Output:
view the top 5 activities of their department, and
CFO/Management user can view the Budget details of last years,
quarter wise and project, Department wise.

Normal Flow:
 Admin adds all master templates
 User login to the portal with appropriate credentials.
 DH and FM can view the top 5 activities related to their department
 CFO and Management user can view the last 5 years budget details
by quarter, project and department.

 System should allow only authorized users to login the page.


Business Rules:

3.2 Add Project

Use Case Name: Add Project

Actors: Application Admin/FM

Description: This functionality is for adding new project to the master for the Budget

Pre-conditions: Users should have login credentials.


Only Application admin or FM can add project.
Duplicate Projects should not be added
Page 14 of 38
Post conditions: The new project which was added to master should viewable for users
 (Mandatory) Login credentials
Input:
 (Mandatory) Project name
The new project will be added to master and should viewable for users
Output:

Normal Flow:
 Application Admin/FM login to portal
 Go to the Projects master and add the new project.
 Cannot add a duplicate project in the system
 After adding the project, it should visible for users to request for
the budget.

 System should allow only authorized users to login the page.


Business Rules:

3.3 Add Activity

Use Case Name: Add activity

Actors: Application Admin/FM

Description: This functionality is for adding new project to the master for the Budget

Pre-conditions:  Only Application admin or FM can add Activity.


 Duplicate activities should not be added.

Post conditions: The new Activity which was added to master should viewable for users
 (Mandatory) Login credentials
Input:
 (Mandatory) Activity name
The new Activity will be added to master and should viewable for users
Output:

Normal Flow:
 Application Admin/FM login to portal
 Go to the Activities master and add the new activity.
 Cannot add a duplicate activity in the System
 After adding the activity, it should visible for users to request for
the budget.

 System should allow only authorized users to login the page.


Business Rules:

Page 15 of 38
3.4 Budget

3.4.1 Budget Opening

Use Case Name: Budget Opening

Actors: CFO

Description: CFO uses this functionality to open a budget for the Financial year for
the duration of configured days

Pre-conditions:  Actor should be only CFO


 CFO must have privileges to open a Budget
 Master templates should create before
 Budget opening date and closing date must be before to the actual
financial year

Post conditions:  Budget opening circular should go to all the departments.


 Alert mails should trigger to department heads to remind due
dates in case budget is not created

 (Mandatory) Budget open date


Input:
 (Mandatory) Budget close Date
M – Mandatory  (Mandatory) Guidelines
 CFO should have privileges to open budget
 Trigger mail to all Department heads with budget guidelines
Output:
details
 Admin adds all master templates
Normal Flow:
 CFO will enter the budget guidelines details and amount for each
department for the financial year.
 CFO opens Budget with starting and ending dates
 Mail will trigger to all department heads along with circulars
 After budget closure date period it will close and not allowed to
create a budget

 System automatically trigger mails to Department heads.


Business Rules:
 System should allow user to initiate budget
 System shall not allow user to request budget for already applied
request.

Page 16 of 38
3.4.2 Budget Request

Use Case Name: Budget Request

Actors: Department Head

Description: All Department heads uses this functionality to initiate a budget


request for the Financial year individually

Pre-conditions: Budget should be open by CFO


Department heads should get the email and circular
User should have the login credentials
Post conditions: Budget request will submitted to CFO approval
Trigger mail to CFO and requester
 (Mandatory) project details
Input:
 (Mandatory) Activity
M – Mandatory  (Mandatory) Quarter
 Amount
 Budget initiate and submit to CFO, Task will open for CFO
Output:
 Department Head or user with appropriate rights will click on
Normal Flow:
budget request option
 User will be guide with the guideline entered form CFO for his
department.
 Department Head then click for initiation were user will enter the
budget details.
 User can submit the request/save as draft/cancel
 New Task is generated for CFO once user submits the request

 System automatically trigger mails to Department heads and CFO


Business Rules:
after request submitted by user. And status changed to initiation.
 when user clicks on submit the data is saved in the system and
status of the request is as Draft
 when user clicks on cancel page is redirected to home page
 System generate a task for CFO

Page 17 of 38
3.4.3 Approve/Reject/clarification Request

Use Case Name: Approve/Reject/Clarification Request

Actors: CFO

Description: This functionality is to approve the request or reject the request or ask
for clarification on budget request submitted by DH

Pre-conditions: DH should submit the request.


New task should generated for the CFO.

Post conditions: Requested user (DH) task is updated a status as per the action taken by
CFO.
 (Mandatory) New task
Input:
M – Mandatory
 Budget request might approved/rejected/ask clarification by CFO
Output:

Normal Flow:
 CFO opens a new task generated for him.
 Verifies the budget request details.
 CFO can take below actions.
 Approve -> Budget is approved and mail is triggered to
the initiated user and CFO and status of the request is
changed to approved.
 Reject -> budget request gets rejected with remarks and
mail triggered is sent to the requested user and CFO
and status of the request is changed to reject.
Note: - re-open request can’t be rejected in the system.
 Clarification-> User enter the remarks submits a mail
triggered and sent to the requested user and CFO and
status of the request is changed to clarification.

 Cancel-> User is redirected to home page


 For requested user task is updated to status as per the action taken
by CFO
 System automatically trigger mails to Department heads, CFO
Business Rules:
approves/rejects/clarification the budget
 System should change the status according to CFO

Page 18 of 38
3.4.4 Clarification

Use Case Name: Clarification

Actors: Requester(DH/user)

Description: This functionality used to give clarification on any request when it is


asked by any level of approvers.

Pre-conditions:  Request clarification to the initiator


 Approver should reviewed and send for clarification
 Mail should trigger to the requester

Post conditions:  Requester will provides clarification re-submit the request for
approval.

(Mandatory)Request with required details


Input:
 Mail trigger to requester saying that request was send for
Output:
clarification
Normal Flow:
 User can submit the request in below cases for approval
 Budget request
 Request for indent
 Renewal for indent
 Reimbursement
 Mail trigger to requester and approver(FM/CFO/Manager)
 Approver opens the task and review the request
 Approver ask for clarification on request
 Requester gets a mail regarding clarification
 Requester will give a clarification on request and re-submits for
approver
 Approver can below actions on request
 Approve: On approve request moves to further steps
 Reject: On reject requests gets closed
 Ask Clarification: Requester need to be give clarification on
request
 System automatically generates tasks for FM.
Business Rules:
 System trigger mails to User, FM, CFO, Manager

Page 19 of 38
3.4.5 Re-open Request

Use Case Name: Re open Request

Actors: CFO

Description: This functionality used to Re-open budget request to modify the


budget, when functional head is requested through mail.

Pre-conditions:  Outside discussion should happened to re-open the approved


project.

Post conditions: CFO can approve or ask for clarification but can’t reject the request
 FM request for modification on budget
Input:

 Task is generated for the requested user


Output:

Normal Flow:
 User can request CFO to re-open the approved budget when user
want some modifications
 CFO re-open request
 Task is generated for the requested user
 User submits the modified request as per remarks system validate
the amount with respect to budget utilized and queued for the
respective request
 CFO can approve or ask for clarification but can’t reject the request
 On the closer of financial year all the request status is closed and
system will not allow any modification for the request with respect
that financial year.
 System automatically generates task for user who requested for re-
Business Rules:
open.

Page 20 of 38
3.5 Procurement

3.5.1 Procurement

Use Case Name: Procurement

Actors: Procurement User

Description: This functionality used for users to raise a request/recurring/service


available for indent for his department.

Pre-conditions:  User should have the login credentials.


 Need to select request/recurring/service available option

Post conditions:  Amount will be deducted from budget on final approval or


request will close.

 (Mandatory) Department
Input:
 (Mandatory) Login credentials
M – Mandatory
 On payment the request get closed from the workflow and moved
Output:
to completed request
 Indent amount get deducted from the budget once the request is
approve from the system
Normal Flow:  User login to procurement home page with login credentials
 User can get three options as 1.Request 2.Recurring 3.Service
available.
 Based on the requirement user will select the option and
follow the respective steps.
 At any approve stage the amount gets deducted from budget
 At any reject stage request gets close
 Procurement request number will be generated in the format
of PR/******(6 digits numeric)/Year.
 System will generate the xml file for the request and integrate
with tally application.
 Procurement user will update the status.

 System will generate the xml file for the request and integrate with
Business Rules:
tally application.
 Indent amount get deducted from the budget once the request is
approve from the system

Page 21 of 38
3.5.2 Request for indent

Use Case Name: Request for indent

Actors: User

Description: This functionality used for users to raise a request for indent for his
department.

Pre-conditions:  User should have the login credentials.


 Need to select project, activity, budget and quarter for indent

Post conditions:  Task is generated for Functional head

 (Mandatory) project details


Input:
 (Mandatory) Activity
M – Mandatory  (Mandatory) Quarter
 Amount and Department
 On payment the request get closed from the workflow and moved
Output:
to completed request
 Indent amount get deducted from the budget once the request is
approve from the system
Normal Flow:  Request for indent can be raise by FM or user with appropriate
right can apply for his department.
 Once the request is initiated task is generated for respective
FM.
 FM can approve or reject the request if approved then based
on amount if say it is less than 5 lakh then it goes to
procurement team else it goes to CFO for approval.
 If CFO approve then it goes to Procurement.
 If CFO reject then it gets closed.
 CFO can send to management for approval.
 Management can approve or Reject
 At any approve stage the amount gets deducted from budget
 On approval from Functional head, CFO and management
when the request is processed to Procurement team.
 Procurement Team will EDIT the form by filling the vendor
details and submits for review to the functional head.
 If there are any discrepancies then Procurement Team will
submit for resubmission to the Functional Head.
 Once the Functional Head Reviews and approves, it moves to
Procurement Team
 Procurement team post the request then data is pushed to
tally.
 The procurement user will update the status.

Page 22 of 38
 The procurement user will submit as payment done then
request is closed

 System will generate the xml file for the request and integrate with
Business Rules:
tally application.
 Indent amount get deducted from the budget once the request is
approve from the system

3.5.3 Recurring/Renewal for indent

Use Case Name: Recurring for indent

Actors: User

Description: This functionality used for users to submit the invoice, and requesting
user as pre-defined amount for approval.

Pre-conditions:  User should have the login credentials.


 User fills the details and uploads the invoice and submits.

Post conditions:  Request is pushed to Tally, amount is deducted from budget

 (Mandatory) Invoice
Input:
 (Mandatory) file size should not exceed 2mb
M – Mandatory  (Mandatory) file type should be pdf/.jpg/.png etc.

Request data is pushed to tally system for generating of invoice for


Output:
the request
Normal Flow:
 User with appropriate rights will request for the indent, based on
the requestor approval limit the request is updated to the
Functional manager or Procurement team.
 In recurring procurement type option for the documents to
upload should be enabled
 Pdf and image file can be uploaded with the file size less than
2mb.
 Request for recurring user fills the details and uploads the
respective documents and submits the request.
 Mail is triggered to the functional manager, requestor and the
procurement user.
 FM tasks, FM logins into the portal and below action is taken
Approve – Request is moved to procurement bucket
Reject -- Request is terminated
Ask approval from CFO-- Request is moved to CFO Bucket
Page 23 of 38
 CFO Logins into the portal below are the action that are available
for the CFO
Approve/Reject/Management approval
 Management user logins into portal below are the actions that
are available for the user.
Approve/Reject
 Procurement user logins into portal below are the actions that are
available for the user
 Procurement user logins into portal below are the actions that are
available for the user
Post/change the status/close

 System should allow only specified format file to upload.


Business Rules:
 System should restrict user not upload file which is more than 2mb

3.5.4 Service Available/ Reimbursement indent

Use Case Name: Service Available

Actors: User

Description: This functionality used for users when user is already purchased
goods and need to request.

Pre-conditions:  User should have the login credentials.


 User purchased goods.

Post conditions:  Push the request to Tally


 Amount gets deducted from Tally

 (Mandatory) Department
Input:
 (Mandatory) Project
M – Mandatory  (Mandatory) Activity
 (Mandatory) Login credentials

 On CFO Approval request, amount will deduct from Tally


Output:

Normal Flow:
 User with appropriate rights will request for the service available
and submits the details.
 In service availed type option for uploading the document is
enabled.
Page 24 of 38
 Pdf and image file can be uploaded with size less than 2mb.
 Mail is triggered to the functional manager, requestor and the
procurement user.
 FM tasks, FM logins into the portal and approve/reject
 CFO Logins into the portal below are the action that are available
for the CFO.
Approve/Reject
 Request is moved to management task a mail is generated to
CFO, Management users, and FM.
 Management user logins into portal and approve/reject the
request.
 At any approve stage the amount gets deducted from budget

 System generates task for FM and CFO.


Business Rules:
 System triggers mail to user

Page 25 of 38
4 Workflow
4.1 BUDGET

Start

Functional head/
Authorised user
goes through the
Guidelines set by
CFO

Functional Head /
authorized user will Selects Activity, Project, inputs the
login to system and Budget amount for FY. Break
submits\resubmit down to Quaterly.
the Budget

Budget details will


be available for No Submitted by
Functional head for Functional Head
Approval

Yes

On Submission a
Functional Head
mail will be sent to
Approves or Edit the
Functional Head and
details and submits
CFO

Rejected A mail is sent to


Approved Functional head on
Decision by CFO?
Rejection or the
clarifications asked

Management
Approval

CFO Asks
Management to
Approve or Reject
the budget

Yes No
Mail sent to
Approved?
Functional head

End

Page 26 of 38
4.1 NEW INDENT

Start

Functional Head /
authorized user will
login to system

Selects Activity,
Project, inputs the
NEW INDENT Budget amount for FY.
Break down to
Quaterly.

Budget details will


be available for No Submitted by
Functional head for Functional Head
Approval

Yes

On Submission a
Functional Head mail will be sent to
Approves or Edit the Functional Head and
details and submits Procurement Team /
CFO

NEW INDENT NEW INDENT


REVIEW – REVIEW –
Functional Head Procurement Team

Approved

YES
Within Allocated Procurement Team
Budget? Approves

NO

Approved A mail is sent to


Rejected
Functional head on
Decision by CFO?
Rejection or the
clarifications asked

Management
Approval

CFO Asks
Management to
Approve or Reject
the budget

No
Mail sent to
Functional head

Yes
Approved?

End

Page 27 of 38
4.2 RENEWAL / RECURRING INDENT

Page 28 of 38
Start

Functional Head /
authorized user will
login to system

Picks from the


Approved INDENT,
RENEWAL \
fields are auto filled.
RECURRING INDENT
Few fields like Amount
Etc., to be filled

Budget details will


be available for No Submitted by
Functional head for Functional Head
Approval

Yes

On Submission a
Functional Head mail will be sent to
Approves or Edit the Functional Head and
details and submits Procurement Team /
CFO

Within Allocated
Budget?
YES

NO
A mail is sent to
Approved Rejected
Procurement Team Functional head on
Decision by CFO?
Approves Rejection or the
clarifications asked

Management Approval

CFO Asks
Management to
Approve or Reject
the budget

Yes No
Mail sent to
Approved?
Functional head

End

Page 29 of 38
4.4 REIMBURSEMENT INDENT

Start

REIMBURSEMENT
INDENT

Functional Head Edit


the details and
submits

On Submission a
Procurement Team mail will be sent to
APPROVED Decision by CFO?
Approves Functional Head and
CFO

Mail sent to
End
Functional head

Page 30 of 38
5 Sample Screen shots

5.1 Application Landing Page

5.2 Budget

Page 31 of 38
5.3 Budget Approve

5.4 Budget clarification

Page 32 of 38
5.5 Department

5.6 Audit Trial

5.7 Budget carry forward

Page 33 of 38
5.7 Budget Task

5.8 Procurement

Page 34 of 38
5.9 Procurement Task

Page 35 of 38
7 Non Functional Requirements
Below are the some of the points that application should support.
 The application must fit into the existing windows machine.
 Provide a web-based user interface for the users.
 Provide responsive base web pages so that they are compatible with mobile and tab.
 Integrate and authentication mechanism with current active directory installation

Page 36 of 38
8 Assumptions/Dependencies

8.1 Assumptions

The new application solution should confirm to the following


 The application will integrate with Active Directory, Tally solution should provide set of user for
installing SharePoint and configuring the SharePoint services.
 BPS application will consume the Rest API from tally for integration of SharePoint BPS solution.
 UAT will be done by tally solution.
 Development of Rest API for integration is not considered part of scope.
 Public IP mapping and host configuration is not part of Tally solution.
 BPS solution will be developed in single language i.e. in English and multi-lingual is not part of
the scope.
 The application will be hosted on Microsoft platform within SharePoint product with version
2013.
 The application will design to support to work IE 10 and above version.

 No Data migration or manual data entry is part of scope

8.2 Dependencies

 The final acceptance testing will be carried out by the Functional Users. The software will be
treated as accepted if it is determined to meet all the system requirements specified in this
document.
 Tally solution should provide the necessary infrastructure for UAT(user Acceptance test)
 Tally solution should provide the necessary H/W and S/W during deploying of application.
 If there is change in requirement then the effort estimation and planned delivery date may
change.

Page 37 of 38
9 Acceptance Criteria
Tally needs to provide Acceptance Test Criteria before the commencement of the Design phase
subsequent to which CMS IT Service will be providing Acceptance Test Plan, which has to be
signed by the client and used during the User Acceptance Test Phase.
Any new requirements/enhancements that arise during the Acceptance testing phase will not
be part of the scope and will be estimated separately.

Page 38 of 38

You might also like