RFP iFMS Odisha

REQUESTFORPROPOSAL
Design,Develop,Implement&Supportof
IntegratedFinanceManagementSystem,
Odisha(iFMSOdisha)

RFPNo.: CompI43/12/19943/DTI
Date: 26/12/2012
FinanceDepartment,
GovernmentofOdisha

Sl.No. Events Date,Time
1. Startdateofissue/saleofRFPdocument 27/12/2012

2. LastdateandtimeforSubmissionofQueries 10/01/2013,5pm
3. PreBidConference 15/01/2013
4. IssueofCorrigendum 28/01/2013

5. Lastdateforissue/saleofRFPDocument 12/02/2013,5pm

6. LastdateandtimeforSubmissionofBid 15/02/2013,5pm
7. OpeningofPreQualificationbids 18/02/2013,11am
8. OpeningofTechnicalbids 18/02/2013,2.30pm

9. PresentationofProofofConcept 25/02/2013

10. OpeningofCommercialbids 11/03/2013

RFP for Design, Develop, Implement and Support iFMSOdisha
Contents
1. FactSheet........................................................................................................................7
2. RequestforProposal........................................................................................................8
3. StructureoftheRFP.........................................................................................................8
4. BackgroundInformation...................................................................................................9
4.1. BasicInformation.............................................................................................................9
4.2. ProjectBackground..........................................................................................................9
4.2.1. AbouttheDepartment.....................................................................................................9
4.2.2. FunctionsofStateGovernmentTreasury......................................................................10
4.2.3. ComputerizationofGovernmentTreasury(OTMS).......................................................10
4.2.4. IntegratedFinanceManagementSystem,Odisha(iFMSOdisha).................................11
4.2.5. Stakeholders...................................................................................................................11
5. InstructionstotheBidders.............................................................................................12
5.1. General...........................................................................................................................12
5.2. CompliantProposals/CompletenessofResponse........................................................12
5.3. PreBidMeeting&Clarifications....................................................................................12
5.3.1. PrebidConference........................................................................................................12
5.3.2. ResponsestoPreBidQueriesandIssueofCorrigendum.............................................13
5.4. KeyRequirementsoftheBid.........................................................................................13
5.4.1. RighttoTerminatetheProcess......................................................................................13
5.4.2. RFPDocumentFees.......................................................................................................13
5.4.3. EarnestMoneyDeposit(EMD).......................................................................................14
5.4.4. SubmissionofProposals................................................................................................14
5.4.5. AuthenticationofBids...................................................................................................15
5.5. PreparationandSubmissionofProposal.......................................................................15
5.5.1. ProposalPreparationCosts............................................................................................15
5.5.2. Language........................................................................................................................15
5.5.3. Venue&DeadlineforSubmissionofProposals.............................................................15
5.5.4. LateBids.........................................................................................................................16
5.6. EvaluationProcess.........................................................................................................16
5.6.1. TenderOpening.............................................................................................................16
5.6.2. TenderValidity...............................................................................................................17
5.6.3. TenderEvaluation..........................................................................................................17
6. CriteriaforEvaluation....................................................................................................18
6.1. PrequalificationCriteria(GeneralBid)...........................................................................18
6.2. BroadTechnicalEvaluationCriteria...............................................................................19
6.3. FinancialEvaluationCriteria..........................................................................................20
6.4. EvaluationMethod.........................................................................................................21
6.5. RankingofBidders.........................................................................................................21
7. AppointmentofServiceProvider....................................................................................22
7.1. AwardCriteria................................................................................................................22
7.2. RighttoAcceptAnyProposalandToRejectAnyorAllProposal(s)..............................22
7.3. NotificationofAward.....................................................................................................22
7.4. ContractFinalizationandAward....................................................................................22
7.5. PerformanceGuarantee................................................................................................22
7.6. SigningofContract.........................................................................................................22
7.7. FailuretoAgreewiththeTermsandConditionsoftheRFP..........................................23
8. TermsofReference........................................................................................................24
8.1. ScopeofWork................................................................................................................24
8.1.1. ProjectManagement.....................................................................................................24
8.1.2. ConductingSystemRequirementStudy........................................................................25
8.1.3. DevelopingSolutionarchitecture&Design....................................................................25
8.1.4. ReorientationofiOTMSasperNewSolutionArchitecture...........................................26
8.1.5. Developing/Customizing/Integrating/ConfiguringSoftware......................................26
8.1.6. DevelopingMIS..............................................................................................................27
8.1.7. PerformingSoftwareTesting.........................................................................................28
8.1.8. PreparingDocumentation..............................................................................................29
8.1.9. SupportingUserAcceptanceTesting.............................................................................29
8.1.10. ConductingPilot.............................................................................................................30
8.1.11. OnlineHelpSystem........................................................................................................30
8.1.12. Training..........................................................................................................................30
8.1.13. RolloutacrossState.......................................................................................................32
8.1.14. Maintenance&SupportServices...................................................................................32
Page|2

8.1.15. HelpDeskOperation......................................................................................................34
8.1.16. SoftwareEnhancementServices....................................................................................35
8.1.17. DataCenterManagement.............................................................................................35
8.1.18. ExitPlan..........................................................................................................................36
8.2. SuggestedBestPractices................................................................................................36
8.2.1. ArchitectureStyle...........................................................................................................36
8.2.2. ArchitectureConstraints................................................................................................37
8.2.3. QualityofService...........................................................................................................39
8.2.4. Integration.....................................................................................................................41
8.2.5. Security..........................................................................................................................42
8.2.6. Databases.......................................................................................................................45
8.2.7. Miscellaneous................................................................................................................45
8.3. Methodology..................................................................................................................46
8.4. ArchitectureforiFMSOdisha........................................................................................47
8.4.1. TechnologyPlatforms....................................................................................................47
8.4.2. PrimaryDataCenter.......................................................................................................47
8.4.3. DisasterRecoverySite....................................................................................................48
8.5. ReportingRequirements................................................................................................49
8.6. FunctionalComponents.................................................................................................50
8.6.1. BudgetPlanning&Preparation.....................................................................................50
8.6.2. DebtManagement.........................................................................................................52
8.6.3. FundManagement.........................................................................................................54
8.6.4. MonitoringofWaysandMeans&RBIIntegration........................................................55
8.6.5. SchemewiseExpenditureTrackingIncurredOutside/InsideConsolidatedFund........58
8.6.6. MonitoringandControllingUtilizationCertificate(UC)................................................60
8.6.7. PensionFinalization,preparationofPensionPaymentOrder(PPO).............................60
8.6.8. TeachersProvidentFund(TPF).....................................................................................63
8.6.9. DocumentManagement................................................................................................65
8.6.10. Works&ForestBillprocessingandAccountsgeneration.............................................66
8.6.11. eDisbursementofGovernmentClaims.........................................................................68
8.6.12. OnlineBillPreparation&Submission............................................................................70
8.6.13. OnlineOfflineBillPreparation&SubmissionModuleIntegration..............................72
Page|3

8.6.14. MobilebasedPaymentandTransactionReporting.......................................................73
8.6.15. Financialdatawarehouse&BudgetDecisionSupportSystems(BDSS)andBusiness
AnalyticandIntelligenceSystem...................................................................................................74
8.6.16. OnlineAudit&Inspection..............................................................................................75
8.6.17. OnlinePaymentrequestfromPLoperator....................................................................78
8.6.18. VirtualTreasury(CyberTreasury)..................................................................................80
8.6.19. NPSincludingESSfortheNewEmployees....................................................................82
8.6.20. CentralizedNPSContributionUploading.......................................................................83
8.6.21. SanctionOrderDatabaseModule..................................................................................86
IntegrationofiFMSOdishawithexistingapplicationiOTMS....................................................88
8.6.22. TreasuryBudgetPlanning&DSSModuleIntegration.................................................88
8.6.23. PaymentTPFModuleintegration...............................................................................89
8.6.24. iOTMSPortalMobileBasedTaxPaymentIntegration................................................91
8.6.25. PaymentEDisbursementModuleIntegration..............................................................92
8.6.26. AccountCorrectioniniOTMS.........................................................................................94
8.6.27. COwiseOnlineReconciliation.......................................................................................95
8.6.28. BudgetDistributionAdvancefromOCFModuleIntegration......................................96
8.6.29. BifurcationofStateshareandCentralsharefromCSP.................................................97
8.6.30. IntegrationwithWorksforestaccounts&WAMIS........................................................98
8.6.31. iOTMSCPSMSPortalIntegration.................................................................................99
8.6.32. IntegrationwithHRMS.................................................................................................100
8.6.33. TreasuryOnlinePaymentRequestbyOperatorModuleIntegration.......................102
8.7. Deliverables..................................................................................................................104
9. KeyPersonnel..............................................................................................................106
10. ProjectTimelines..........................................................................................................108
10.1. ImplementationPhases...............................................................................................108
10.2. ImplementationSchedule............................................................................................111
10.3. GovernanceStrategy....................................................................................................112
11. ServiceLevelAgreement..............................................................................................113
11.1. CompensationforTerminationofContract.................................................................113
11.2. LiquidatedDamages.....................................................................................................113
Page|4

11.3. QualityoftheSoftware................................................................................................113
11.4. SystemUptime&Performance...................................................................................113
11.5. Training........................................................................................................................113
11.6. HelpdeskSupport.........................................................................................................113
11.7. Pilottestingandrollout...............................................................................................114
12. AcceptanceTestingandCertification............................................................................115
12.1. FunctionalRequirementsReview................................................................................116
12.2. SecurityReview............................................................................................................116
12.3. Performance................................................................................................................116
12.4. SLAReportingSystem..................................................................................................116
12.5. ProjectDocumentation................................................................................................117
12.6. DataQuality.................................................................................................................117
13. PaymentSchedules......................................................................................................118
14. AcceptanceCriterion....................................................................................................119
15. FraudandCorruptPractices.........................................................................................121
AppendixI:PreQualificationTemplates..............................................................................122
Form1:ComplianceSheetforPreQualificationProposal......................................................122
Form2:ParticularsoftheBidder.............................................................................................123
Form3:BankGuaranteeforEarnestMoneyDeposit..............................................................124
AppendixII:TechnicalProposal...........................................................................................126
Form4:ComplianceSheetforTechnicalProposal...................................................................126
Form5:BidLetter(TechnicalBid)............................................................................................127
Form6:FormatforListofProjectsExecutedinLast3Years...................................................128
Form7:ProjectCitationFormat...............................................................................................129
Form8:ProposedSolution.......................................................................................................131
Form9:ProposedWorkPlan...................................................................................................132
Form10:TeamComposition....................................................................................................133
Page|5

Form11:FormatofCVforProposedTechnicalStaffofBidder...............................................134
Form12:DeploymentofPersonnel.........................................................................................136
AppendixIII:FinancialProposalTemplate............................................................................137
Form13:ComplianceSheetforFinancialProposal.................................................................137
Form14:BidLetter(FinancialBid)...........................................................................................138
Form15:MasterRateChartofManpower..............................................................................140
Form16:CostofSoftwareDevelopment&Integration..........................................................141
Form17:CostofTraining.........................................................................................................143
Form18:CostofPilotTesting&Rollout..................................................................................145
Form19:CostofHelpdeskOperation......................................................................................146
Form20:CostofMaintenance&Support...............................................................................147
Form21:CostofSoftwareEnhancementServices..................................................................148
Form22:FinancialProposal.....................................................................................................149
AppendixIV:TemplateforPBG............................................................................................150
Form23:PerformanceBankGuarantee..................................................................................150
Page|6

1. FactSheet
This Fact Sheet comprising of important factual data on the tender is for quick reference of the
bidder.
ClauseReference Topic
Section6.4 QualityandCostBasedSelection(QCBS)methodshallbeusedtoselectthe
service provider to design, develop, implement and support integrated
FinanceManagementSystem,Odisha(iFMSOdisha).Thebidderhastoapply
the bid in three envelop system, General (Prequalification), Technical &
Financialbid.TechnicalbidofthosebidderswhoqualifiesinGeneralBidshall
be opened. Financial bid of those bidders who qualify in Technical Bid by
scoring 70% or above shall be opened. Highest scorer with 70% weight in
Technical Bidding and 30% weight in Financial will win the bid. Consortium
notallowed.
Section5.4.2 RFP can be Downloaded from https://www.odishatreasury.gov.in or

https://www.odisha.gov.in. The bidders are required to submit the
document Fee of Rs. 10,400 by Demand Draft in favour of Director of
TreasuriesandInspectionandpayableatGovernmentTreasuryBranch,SBI,
Bhubaneswar from any of the scheduled commercial bank along with the
Proposal.
Section5.4.3 EarnestMoneyDepositofamountRs.20lakhsbyDemandDraftinfavourof
DirectorofTreasuriesandInspectionandpayableatGovernmentTreasury
Branch,SBI,BhubaneswarfromanyoftheScheduledBankORBank
GuaranteeasmentionedinAppendixIForm3
Section8 ThisprojectincludesdeliverablesrelatingtoSoftwareDevelopment,Training
andHandholding,SupportServices.SourceCodeoftheSoftwareApplication,
Reportsandothertechnicaldocumentsrelatingtoeachofaboveactivities
areimportantdeliverablesofthisproject.
Section10.2 Totalprojectperiodis5years.Therewillbe3phasestodevelopsoftware
modules of iFMSOdisha, integrate them with iOTMS, HRMSOdisha,
WAMIS,CPSMS,VLC&otherexistingsoftwareandimplementitacrossthe
state.Serviceprovidermustcompleteallthreephasewithin27monthsfrom
receiving the work order. Post implementation maintenance and support
servicemustbeprovidedforaperiodof45months.Helpdesksupporthasto
beprovidedforaperiodof51months.Theserviceprovidermusthandover
alldeliverablestotheProjecteMissionTeam(PeMT)ofFinanceDepartment
andexitsuccessfullywithinstipulatedtime.
Section5.3 ApreBidmeetingwillbeheldonJanuary15atTreasury&Accounts
Bhawan,UnitIII,KharavelNagar,Bhubaneswar.
Thename,address,andtelephonenumbersoftheNodalOfficeris:
Smt.PranatiChhotray
Asst.Director
Page|7

ClauseReference Topic
DirectorateofTreasuriesandInspection
Phone:06742395031
Fax:06742531142
pranatichhotray@orissatreasury.gov.in
AllthequeriesshouldbereceivedonorbeforeJanuary10,2013,5pm,
throughemailonlyattheabovementionedaddress.
Section5.5.2 TheProposalshouldbefilledbytheBidderinEnglishlanguageonly.
ThebiddershouldquotepriceinIndianRupeesonly.Theofferedpricemust
beexclusiveoftaxesandduties.Thetaxesasappropriate&applicablewould
Section13 bepaidattheprevalentrates.
Proposals/Bidsmustremainvalid180daysafterthesubmissiondate,i.e.,
Section5.6.2 untilAugust15,2013.
Section5.4.5 Bidders must submit An original copy and one additional copies of each
proposal along with one copy of noneditable CD for Prequalification &
TechnicalProposal.
OneoriginalcopyoftheCommercialProposal
Section5.5.3 Theproposalsubmissionaddressis:
DirectorofTreasuriesandInspection,Odisha,Bhubaneswar
SriP.P.Nath
DirectorofTreasuriesandInspection
Treasury&AccountsBhawan,UnitIII,KharavelNagar,Bhubaneswar
Phone:06742390725
Fax:06742531142
Email:dticentrallocation@gmail.com,dtihelpdesk@orissatreasury.gov.in
Section5.5.3 ProposalsmustbesubmittedonorbeforeFebruary15,2013,5pm.
2. RequestforProposal
Sealed tenders are invited from eligible, reputed, qualified Software Application Developers and
Implementers as detailed out in the Scope of Work under Section 8 of this RFP Document. This
invitation to bid is open to all Bidders meeting the minimum eligibility criteria as mentioned in
Section6.1ofthisRFPDocument.
3. StructureoftheRFP
ThisRequestforProposal(RFP)documentfortheprojectofDesign,Develop,Implement&Support
IntegratedFinanceManagementSystem,Odisha(iFMSOdisha)forFinanceDepartmentGovernment
Page|8

ofOdishacompriseofthefollowing.
I. InstructionsontheBidprocessforthepurposeofrespondingtothisRFP.Thisbroadlycovers:
a. Generalinstructionsforbiddingprocess
b. Bid evaluation process including the parameters for Prequalification, Technical
evaluationandcommercialevaluationtofacilitateFinanceDepartment,Government
ofOdishaindeterminingbidderssuitabilityastheimplementationpartner
c. Paymentschedule
d. Commercialbidandotherformats
II. FunctionalandTechnicalRequirementsoftheproject.Thecontentsofthedocumentbroadly
coverthefollowingareas:
a. Abouttheprojectanditsobjectives
b. Scopeofwork
c. FunctionalandTechnicalrequirements
d. ProjectSchedule
e. Servicelevelsfortheimplementationpartner
Thebidderisexpectedtorespondtotherequirementsascompletelyandinasmuchrelevantdetail
as possible, and focus on demonstrating bidders suitability to become the Software developer &
ImplementationpartnerofFinanceDepartment,GovernmentofOdisha.
Thebiddersareexpectedtoexamineallinstructions,forms,terms,Projectrequirementsandother
information in the RFP documents. Failure to furnish all information required as mentioned in the
RFP documents or submission of a proposal not substantially responsive to the RFP documents in
everyrespectwillbeattheBidder'sriskandmayresultinrejectionoftheproposal.
4. BackgroundInformation
4.1. BasicInformation
a) Finance Department, Government of Odisha invites responses (Tenders) to this Request
for Proposals (RFP) from Systems Implementation Agencies/ Partners (Bidders) for the
provision of Design, Develop, Implement and Support of Integrated Finance Management
System,Odisha,(iFMSOdisha)asdescribedinSection8ofthisRFP,TermsofReference.
b) Proposals must be received not later than time, date and venue mentioned in the Fact
Sheet.Proposalsthatarereceivedlatewillnotbeconsideredinthisprocurementprocess.
c) Department will award the Contract to the successful bidder whose proposal has been
determined as the bestvalue proposal based on Technical and Financial evaluation criteria
andacceptedbytheTenderAcceptingAuthority.
4.2. ProjectBackground
4.2.1. AbouttheDepartment
The Department of Finance, Government of Odisha monitors all receipts and expenditures of the
state.TheDepartmentalsolooksaftertheallocationandmonitoringofbudget;assessingavailability
offundsforvariousschemesandmonitoringthestatusofgovernmentinvestmentinequities,loans,
Page|9

etc.Ensuringproperfinancialmanagementandmonitoringofauditalsofallsunderthejurisdiction
oftheFinanceDepartment.
4.2.2. FunctionsofStateGovernmentTreasury
Directorate of Treasuries and Inspection (D.T.I.) Odisha is the heads of department under Finance
Department.Thereare30DistrictTreasuries,8SpecialTreasuries,1CyberTreasuriesand126Sub
Treasuries under respective jurisdiction of District Treasuries. Directorate of Treasuries and
Inspection(D.T.I.)Odishawasestablishedintheyear1962;theprimaryfunctionsbeingtoactasthe
HeadsofDepartmentfortheTreasuriesandSubTreasuriesintheState.TheD.T.I.Odishamonitors
this primary activity on monthly basis and acts as the administrative head for these treasuries as
well. In addition to these,inspection activityof alltheTreasuries is done on aregularbasis which
includetheverificationofstockofstampsandvaluablesinthestrongroom,billtransactiondetails,
verificationofpensionrelatedissues,P.L.Accountoperations,andotheralliedactivitiesattreasuries
andSubTreasurieslevels.

FIG:1:TREASURYADMINISTRATIONINFINANCEDEPARTMENT
4.2.3. ComputerizationofGovernmentTreasury(OTMS)
The computerization of Odisha Treasury dates back to 2001. NIC first implemented District
Computerization in 2001. This system was implemented in 21 District Treasuries. The System was
chieflyusedforAccountsPreparation.Laterintheyear2007,OdishaTreasuryManagementsystem
(OTMS)wasimplemented.ItisafacilitywithinthesystemforonlineTreasuryfunctions.Themajor
functionsunderOTMSincludebudgetdistribution,transmissionofbudgetdatabothinphysicalas
wellaselectoralmodeonlineandpassingofgovernmentbills.Therehasbeenadedicatedteamof
professionalsbothfromTreasuryandfromtheimplementationagencyandthroughtheirdedicated
efforttherealtimeintegrationofthesystemwasachievedintheyear2007justaboutoneandhalf
yearfromthedateofconceptualization.Thehighlightsofthisprojectare:
InitialDevelopmentandImplementationofthesystemwassupportedbyDFID,UK
Thedevelopmentofthesystemstartedin2004.
TheSystemwentlivein2006
ThesystemwasdevelopedbyCMCLtd.
Thesystemusedclient/serverarchitectureusingOracleDeveloper2000tools
ThesystemusedOracle10gDatabasefordatastoragepurpose
Page|10

The System used distributed data storage architecture. The Data was stored in individual
treasuries.
ThedatawassynchronizedwiththeHeadQuarterdatabaseperiodically.
ThemajorfunctionsunderO.T.M.S.includebudgetdistribution,transmissionofbudgetdata
both in physical as well as electoral mode on line passing of government bills physically
submittedtotheTreasury.
4.2.4. IntegratedFinanceManagementSystem,Odisha(iFMSOdisha)
After reviewing the success of iOTMS, the Government of Odisha is contemplating
implementationofiFMSOdisha.Thisversionwilltakeintoaccountconcernsofthestakeholdersand
implement additional functions to bring efficiency, effectiveness in decision making and business
intelligencetotheapplications.Detailsaboutthescopeandfunctionalityoftheproposedsolution
aredescribedinSection8(TermsofReference).
4.2.5. Stakeholders
Theproposedsystemhavebasicallytwotypesofstakeholders,thosearePrimaryStakeholders
andSecondaryStakeholders.Categorywiselistofstakeholdersaregivenbelow:
a. PrimaryStakeholders
FinanceDepartment(FD)
Planning&CoordinationDepartment(P&CD)
OtherAdministrativeDepartments(AD)
DirectorofTreasuriesandInspection(DTI)
BudgetControllingOfficersforTreasurydrawalandPublicWorksExpenditure(CO)
Drawing&DisbursingOfficers/Divisions/FA&COs(DDO)
Treasuries
AccountantGeneral(AG),Odisha
ControllerofAccounts(CoA)
b. SecondaryStakeholders
PublicSectorBanksPensioners
Citizen
Employees
ReserveBankofIndia(RBI)
CentralPlanSchemeMonitoringSystem,DeptofExpenditure,MinistryofFinance
(CPSMS)
DepartmentandCommissionsforonlinesharingofreceiptconfirmation.
Page|11

5. InstructionstotheBidders
5.1. General
a) While every effort has been made to provide comprehensive and accurate background
informationandrequirementsandspecifications,Biddersmustformtheirownconclusions
aboutthesolutionneededtomeettherequirements.BiddersandrecipientsofthisRFPmay
wishtoconsulttheirownlegaladvisersinrelationtothisRFP.
b) AllinformationsuppliedbyBiddersmaybetreatedascontractuallybindingontheBidders,
onsuccessfulawardoftheassignmentbytheFinanceDepartmentonthebasisofthisRFP.
c) No commitment of any kind, contractual or otherwise shall exist unless and until a formal
written contract has been executed by or on behalf of the Finance Department. Any
notificationofpreferredbidderstatusbytheFinanceDepartmentshallnotgiverisetoany
enforceable rights by the Bidder. The Finance Department may cancel this public
procurementatanytimepriortoaformalwrittencontractbeingexecutedbyoronbehalfof
theFinanceDepartment.
d) This RFP supersedes and replaces any previous public documentation & communications,
andBiddersshouldplacenorelianceonsuchcommunications.
5.2. CompliantProposals/CompletenessofResponse
a) Bidders are advised to study all instructions, forms, terms, requirements and other
informationintheRFPdocumentscarefully.Submissionofthebidshallbedeemedtohave
beendoneaftercarefulstudyandexaminationoftheRFPdocumentwithfullunderstanding
ofitsimplications.
b) Failure to comply with the requirements of this paragraph may render the Proposal non
compliantandtheProposalmayberejected.Biddersmust:
i. IncludealldocumentationspecifiedinthisRFP;
ii. FollowtheformatofthisRFPandrespondtoeachelementintheorderassetoutin
thisRFP
iii. ComplywithallrequirementsassetoutwithinthisRFP.
5.3. PreBidMeeting&Clarifications
5.3.1. PrebidConference
a) Finance Department shall hold a prebid meeting with the prospective bidders on January
15,2013atTreasury&AccountsBhawan,UnitIII,KharavelNagar,Bhubaneswar.
b) TheBidderswillhavetoensurethattheirqueriesforPreBidmeetingshouldreachto
Smt.PranatiChhotray
Asst.Director
DirectorateofTreasuriesandInspection
Phone:06742395031
Fax:06742531142
Page|12

pranatichhotray@orissatreasury.gov.in
onlybyemailonorbeforeJanuary10,2013,5pm.
c) Thequeriesshouldnecessarilybesubmittedinthefollowingformat:
RFPDocumentReference(s) ContentofRFPrequiring
S.No. Pointsofclarification
(Section&PageNumber(s)) Clarification(s)
1.
2.
3.
d. Finance Department shall not be responsible for ensuring that the bidders queries have
beenreceivedbythem.Anyrequestsforclarificationsposttheindicateddateandtimemay
notbeentertainedbytheFinanceDepartment.
5.3.2. ResponsestoPreBidQueriesandIssueofCorrigendum
a. The Nodal Officer notified by the Finance Department will endeavor to provide timely
response to all queries. However, Finance Department neither makes representation or
warrantyastothecompletenessoraccuracyofanyresponsemadeingoodfaith,nordoes
Finance Department undertake to answer all the queries that have been posed by the
bidders.
b. At any time prior to the last date for receipt of bids, Finance Department may, for any
reason, whether at its own initiative or in response to a clarification requested by a
prospectiveBidder,modifytheRFPDocumentbyacorrigendum.
c. The Corrigendum (if any) & clarifications to the queries from all bidders will be posted on
https://www.odishatreasury.gov.in, https://www.odisha.gov.in and emailed to all
participantsoftheprebidconference.
d. AnysuchcorrigendumshallbedeemedtobeincorporatedintothisRFP.
e. In order to provide prospective Bidders reasonable time for taking the corrigendum into
account,FinanceDepartmentmay,atitsdiscretion,extendthelastdateforthereceiptof
Proposals.
5.4. KeyRequirementsoftheBid
5.4.1. RighttoTerminatetheProcess
a. FinanceDepartmentmayterminatetheRFPprocessatanytimeandwithoutassigningany
reason.FinanceDepartmentmakesnocommitments,expressorimplied,thatthisprocess
willresultinabusinesstransactionwithanyone.
b. ThisRFPdoesnotconstituteanofferbyFinanceDepartment.Thebidder'sparticipation in
this process may result Finance Department selecting the bidder to engage towards
executionofthecontract.
5.4.2. RFPDocumentFees
a. RFP document can be downloaded from https://www.odishatreasury.gov.in or
https://www.odisha.gov.in. The bidders are required to submit the document Fee of
Rs.10,400/byDemandDraftinfavourofDirectorofTreasuriesandInspectionandpayable
Page|13

atGovernmentTreasuryBranch,SBI,Bhubaneswarfromanyof thescheduledcommercial
bankalongwiththeProposal.ProposalsreceivedwithoutorwithinadequateRFPDocument
feesshallberejected.
5.4.3. EarnestMoneyDeposit(EMD)
a. Bidders shall submit, along with their Bids, EMD of Rs. 20 lakhs only, in the form of a
DemandDraftORBankGuarantee(intheformatspecifiedinAppendixI:Form3)issuedby
anyscheduledbankinfavorofDirectorofTreasuriesandInspection,payableatGovernment
TreasuryBranch,SBI,Bhubaneswar,andshouldbevalidfor180daysfromtheduedateof
thetender/RFP.
b. EMDofallunsuccessfulbidderswouldberefundedbyFinanceDepartmentwithin180days
of the bidder being notified as being unsuccessful. The EMD, for the amount mentioned
above, of successful bidder would be returned upon submission of Performance Bank
GuaranteeaspertheformatprovidedinAppendixIV:Form1.
c. TheEMDamountisinterestfreeandwillberefundabletotheunsuccessfulbidderswithout
anyaccruedinterestonit.
d. Thebid/proposalsubmittedwithoutEMD,mentionedabove,willbesummarilyrejected.
e. TheEMDmaybeforfeited:
Ifabidderwithdrawsitsbidduringtheperiodofbidvalidity.
Incaseofasuccessfulbidder,ifthebidderfailstosignthecontractinaccordance
withthisRFP.
If found to have a record of poor performance such as having abandoned work,
having been blacklisted, having inordinately delayed completion and having faced
Commercialfailuresetc.
5.4.4. SubmissionofProposals
a. The bidders should submit their responses as per the format given in this RFP in the
followingmanner
Response to PreQualification Criterion : (1 Original + 1 Copies + 1 CD) in first
envelope
TechnicalProposal(1Original+1Copies+1CD)insecondenvelope
CommercialProposal(1Original)inthirdenvelope
b. TheResponsetoPreQualificationcriterion,TechnicalProposalandCommercialProposal(As
mentioned in previous paragraph) should be covered in separate sealed envelopes super
scribing PreQualification Proposal, "Technical Proposal" and Commercial Proposal
respectively. Each copy of each bid should also be marked as "Original" OR "Copy" as the
casemaybe.
c. PleaseNotethatPricesshouldnotbeindicatedinthePreQualificationProposalorTechnical
ProposalbutshouldonlybeindicatedintheCommercialProposal.
d. ThethreeenvelopescontainingcopiesofPrequalificationProposal,TechnicalProposaland
Commercial Proposal should be put in another single sealed envelope clearly marked
Response to RFP for Design, Develop, Implement & Support of Integrated Finance
ManagementSystem,OdishaCompI43/12/19943/DTIdated26.12.2012andthewordings
DONOTOPENBEFOREFebruary18,2013.
Page|14

e. Theouterenvelopethuspreparedshouldalsoindicateclearlythename,address,telephone
number,EmailIDandfaxnumberofthebiddertoenabletheBidtobereturnedunopened
incaseitisdeclared"Late".
f. All the pages of the proposal must be sequentially numbered and must contain the list of
contents with page numbers. Any deficiency in the documentation may result in the
rejectionoftheBid.
g. Theoriginalproposal/bidshallbepreparedinindelibleink.Itshallcontainnointerlineations
or overwriting, except as necessary to correct errors made by the bidder itself. Any such
correctionsmustbeinitialedbytheperson(orpersons)whosign(s)theproposals.
h. All pages of the bid including the duplicate copies, shall be initialed and stamped by the
personorpersonswhosignthebid.
i. IncaseofanydiscrepancyobservedbyFinanceDepartmentinthecontentsofthesubmitted
originalpaperbiddocumentswithrespectivecopies,theinformationfurnishedonoriginal
paperbiddocumentwillprevailoverothers.
j. Biddermustensurethatthe informationfurnishedbyhiminrespectiveCDsis identicalto
that submitted by him in the original paper bid document. In case of any discrepancy
observed by Finance Department in the contents of the CDs and original paper bid
documents,theinformationfurnishedonoriginalpaperbiddocumentwillprevailoverthe
softcopy.
5.4.5. AuthenticationofBids
A proposal should be accompanied by a powerofattorney in the name of the signatory of the
proposal.
5.5. PreparationandSubmissionofProposal
5.5.1. ProposalPreparationCosts
The bidder shall be responsible for all costs incurred in connection with participation in the RFP
process,including,butnotlimitedto,costsincurredinconductofinformativeandotherdiligence
activities, participation in meetings/ discussions/ presentations, preparation of proposal, in
providing any additional information required by Finance Department to facilitate the evaluation
process,andinnegotiatingadefinitivecontractorallsuchactivitiesrelatedtothebidprocess.
FinanceDepartmentwillinnocaseberesponsibleorliableforthosecosts,regardlessoftheconduct
oroutcomeofthebiddingprocess.
5.5.2. Language
The Proposal should be filled by the Bidder in English language only. If any supporting documents
submittedareinanylanguageotherthanEnglish,translationofthesameinEnglishlanguageistobe
dulyattestedbytheBidders.ForpurposesofinterpretationoftheProposal,theEnglishtranslation
shallgovern.
5.5.3. Venue&DeadlineforSubmissionofProposals
Proposals,initscompleteforminallrespectsasspecifiedintheRFP,mustbesubmittedtoFinance
Departmentattheaddressspecifiedbelow:
Page|15

AddressedTo SriP.P.Nath,DirectorofTreasuriesandInspection
DirectorofTreasuriesandInspection,Odisha,
Name Bhubaneswar
Treasury&AccountsBhawan,UnitIII,KharavelNagar,
Address Bhubaneswar
Telephone 06742390725
FaxNos. 06742531142
dticentrallocation@gmail.com
Emailids dtihelpdesk@orissatreasury.gov.in
LastDate&TimeofSubmission February15,2013at5pm
5.5.4. LateBids
a. Bids received after the due date and the specified time (including the extended period if
any)foranyreasonwhatsoever,shallnotbeentertainedandshallbereturnedunopened.
b. The bids submitted by telex/ telegram/ fax/ email etc. shall not be considered. No
correspondencewillbeentertainedonthismatter.
c. Finance Department shall not be responsible for any postal delay or nonreceipt/ non
deliveryofthedocuments.Nofurthercorrespondenceonthesubjectwillbeentertained.
d. Finance Department reserves the right to modify and amend any of the abovestipulated
condition/criteriondependinguponprojectprioritiesvisvisurgentcommitments.
5.6. EvaluationProcess
a. Finance Department will constitute a Proposal Evaluation Committee to evaluate the
responsesofthebidders
b. The Proposal Evaluation Committee constituted by the Finance Department shall evaluate
theresponsestotheRFPandallsupportingdocuments/documentaryevidence.Inabilityto
submitrequisitesupportingdocuments/documentaryevidence,mayleadtorejection.
c. ThedecisionoftheProposalEvaluationCommitteeintheevaluationofresponsestotheRFP
shall be final. No correspondence will be entertained outside the process of negotiation/
discussionwiththeCommittee.
d. The Proposal Evaluation Committee may ask for meetings with the Bidders to seek
clarificationsontheirproposals
e. TheProposalEvaluationCommitteereservestherighttorejectanyorallproposalsonthe
basisofanydeviations.
f. Eachoftheresponsesshallbeevaluatedasperthecriterionsandrequirementsspecifiedin
thisRFP.
5.6.1. TenderOpening
TheProposalssubmitteduptoFebruary15,2013,5pmwillbeopenedonFebruary18,2013at11am
Page|16

byNodalofficer(Smt.PranatiChhotray,Asst.Director,DirectorateofTreasuriesandInspection)or
any other officer authorized by Finance Department, in the presence of such of those Bidders or
theirrepresentativeswhomaybepresentatthetimeofopening.Therepresentativesofthebidders
should be advised to carry the identity card or a letter of authority from the tendering firms to
identifytheirbonafidesforattendingtheopeningoftheproposal.
5.6.2. TenderValidity
TheoffersubmittedbytheBiddersshouldbevalidforminimumperiodof180daysfromthedateof
submissionofTender.
5.6.3. TenderEvaluation
a. InitialBidscrutinywillbeheldandincompletedetailsasgivenbelowwillbetreatedasnon
responsive.IfProposals;
ArenotsubmittedinasspecifiedintheRFPdocument
ReceivedwithouttheLetterofAuthorization(PowerofAttorney)
Arefoundwithsuppressionofdetails
Withincompleteinformation,subjective,conditionaloffersandpartialofferssubmitted
Submittedwithoutthedocumentsrequestedinthechecklist
HavenoncomplianceofanyoftheclausesstipulatedintheRFP
Withlesservalidityperiod
b. AllresponsiveBidswillbeconsideredforfurtherprocessingasbelow.
FinanceDepartmentwillpreparealistofresponsivebidders,whocomplywithalltheTerms
andConditionsoftheTender.Alleligiblebidswillbeconsideredforfurtherevaluationbya
CommitteeaccordingtotheEvaluationprocessdefineinthisRFPdocument.Thedecisionof
theCommitteewillbefinalinthisregard.
Page|17

6. CriteriaforEvaluation
Tenders for this contract will be assessed in accordance with Quality and Costbased Selection
(QCBS) system. All bids will primarily be evaluated on the basis of Prequalification Criteria. The
ProposalEvaluationCommitteewillcarryoutadetailedevaluationoftheProposals,onlythosewho
qualifies all Prequalification criteria, in order to determine whether the technical aspects are in
accordance with the requirements set forth in the RFP Documents. In order to reach such a
determination,theProposalEvaluationCommitteewillexamineandcomparethetechnicalaspectof
theProposalsonthebasisofinformationprovidedbythebidder,takingintoaccountthefollowing
factors:
a. Overallcompletenessandcompliancewiththerequirement
b. Proposed workplan and methodology shall demonstrate that the bidder will achieve the
performancestandardswithinthetimeframedescribedinRFPdocuments
c. Proposedsolutionanddemonstrationofproofofconcept
d. Anyotherrelevantfactors,ifany,listedinRFPdocument,ortheFinanceDepartmentdeems
necessaryorprudenttotakeintoconsideration
Inordertofacilitatethetechnicalproposalevaluation,thetechnicalcriterialaiddownalongwiththe
assignedweightshavebeenpresentedinsubsequentsection.Themarkingschemepresentedhereis
an indication of the relative importance of the evaluation criteria. Bidders securing a minimum of
70% marks in the technical evaluation will only be considered for further financial bid evaluation.
Bids of Tenders which dont secure the minimum specified technical score will be considered
technicallynonresponsiveandhencedebarredfrombeingconsideredforfinancialevaluation.
6.1. PrequalificationCriteria(GeneralBid)
Keepinginviewthecomplexity&volumeoftheworkinvolved,thefollowingcriteriaare
prescribedasprequalificationcriteriafortheBidderinterestedinundertakingtheproject.
Consortiumisnotallowed.TechnicalBidsofonlythesuccessfulprequalifierswillbeopenedfor
evaluation.
a. TheOrganizationmustberegisteredundertheCompaniesAct1956andmusthavebeenin
operationforaperiodofatleast5(five)yearsasofMarch31,2012.
b. Thefirm/companymusthaveminimumaverageannualturnoverofRs.500croresoverthe
precedingthreefinancialyearsasrevealedbyauditedaccounts,asonMarch31,2012.
c. The Bidder must have at least 1,000 technically qualified professionals having minimum
qualification of B.E/ MCA or higher having 2 or more years of experience as on March 31,
2012onitspayroll.
d. Bidder must have implemented at least One eGovernance projects with minimum order
valueofRs.10Crore(RupeesTenCroreOnly)includinghardware&networkingcomponents
orofRs.5Crore(RupeesFiveCroreOnly)excludinghardware&networkingcomponentsin
last 5 financial years ending March 31, 2012. 'EGovernance projects' is defined as design,
development and implementation and maintenance support (ongoing/ completed) of IT
systemforagovernment/publicsectorenterprisesinIndia.
Page|18

e. ThebiddermusthavecleareduptodateVAT/ServiceTax.
f. The bidder must possess SEICMMi Level 5, ISO IEC 9001 Certification by the date of
publicationofthisRFP.
g. Incasethebidderproposepredevelopedproduct(s)/solutionthenthebiddermustown/
have stake in the IPR & Source Code of the solution/ product/ solution framework being
offeredunderthisRFP.
h. Applicants must not be under a declaration of ineligibility for corrupt and fraudulent
practicesissuedbyGovt.ofIndia/StateGovt.
i. The Bidder must have submitted Rs. 10, 400/ (Rupees ten thousand four hundred only
includingVAT)towardsthecostoftheTenderDocument.
j. TheBiddermusthavefurnishedtheEMDofRs.20Lakhs(Rupeestwentylakhsonly).
k. TheBiddermustnothaveanyrecordofpoorperformance,abandonedwork,havingbeen
blacklisted by any state government or government of India, having inordinately delayed
completionandhavingfacedCommercialfailuresetc.
The Finance Department, Government of Odisha, if required, would visit/ enquiry the sites
mentioned by the bidder as Relevant Experience to verify the level of implementation,
completenessanddetailsrelatedtothelongtermsustainabilityandotheraspectoftheproject.
6.2. BroadTechnicalEvaluationCriteria
CRITERIA MAX
MARKS
BiddersExperienceofSuccessfulCompletionofProjectsofSimilarNature
BiddershouldsubmitdetailsofonlyTreasury/GovernmentFinance
Managementprojectswithsoftwaredevelopmentvaluemorethan
Rs.50LakhsortotalprojectvaluemorethanRs.2Croreasproofof
their experience in relevant projects. Bidder will be awarded score
outofmaximum10Marks.
Biddershouldsubmitdetailsofsoftwareprojects(otherthanabove)
with software development value more than Rs. 1 Crore or total 25
projectvaluemorethanRs.4Croreasproofoftheirexperiencein
managinglargeandcomplexprojects.Bidderwillbeawardedscore
outofmaximum10Marks.
Bidder should submit details of eGovernance projects executed in
India (other than above) with software development value more
thanRs.1CroreortotalprojectvaluemorethanRs.4Croreasproof
oftheirexperienceinmanaginglargeandcomplexprojects.Bidder
willbeawardedscoreoutofmaximum5Marks.
Page|19

CRITERIA MAX
MARKS
ServiceProvider'sResponsivenesstotheToR,AppreciationoftheProject
andSuggestedMethodology,Innovation,QualityAssuranceandExtentof
Details,FeasibilityofImplementationPlan
ClarityinunderstandingoftheobjectivityofToR(15Marks) 50
ArchitectureofproposedsolutionandProofofConcept(10Marks)
Robustmethodologysuggested(15Marks)
Innovationsinproposedsolution(10Marks)
KeyPersonnel(GeneralQualifications,AppropriateExperienceandTrack
Record,ExperienceintheRegion/State,BackUpSupport,Availabilityand
CertaintyofObtainingNamedIndividualsetc.)andManagementStructure
ofTeam 25
Number,profileandyearsofexperienceofkeypeopleproposed
ManagementStructureoftheTeam
TOTAL 100

Minimumabsolutetechnicalscoretoqualifyforcommercialevaluationis70.
Theindividualbiddertechnicalscoreswillbenormalizedaspertheformulabelow:
Tn=(Tb/Tmax)X100
Where,
Tn=normalizedtechnicalscoreforthebidderunderconsideration
Tb=absolutetechnicalscoreforthebidderunderconsideration
Tmax=maximumabsolutetechnicalscoreobtainedbyanybidder
6.3. FinancialEvaluationCriteria
Arithmeticalerrorswillberectifiedonthefollowingbasis.Amountmentionedinwordwillprevail
againstthefigureincaseofanydiscrepancyinFinancialProposal.Incaseofanydiscrepancyinthe
calculatedamount,theamountwillbecalculatedwiththebaserates(Form15:MasterrateChartof
Manpower)providedbythebidderandwillbeusedforthepurposeofevaluationandsubsequent
agreementifany.
ThefollowingformatwouldbeusedforevaluationoffinancialscoreD=100Xfmin/f.
Wheref=Pricequotedexcludingoftaxesandduties
Page|20

fmin=Lowestpricequotedamongallbidders
NameoftheBidder FinancialEvaluation
PriceQuoted FinancialScore
(f) D=100fmin/f

6.4. EvaluationMethod
TendersforthiscontractwillbeassessedinaccordancewithQualityandCostbased
Selection(QCBS)systemandwillinvolvebothtechnicalandcommercialevaluationwiththe
followingweightage:
TechnicalEvaluation(T) TnX0.7
CommercialEvaluation(C) DX0.3
TotalScore T+C
6.5. RankingofBidders
Afterfinancialevaluationofthebids,finalscoreofeachbidderwillbetabulated.Thebidder
thatwillsecurehighestfinalscorewillberankedoneandwillbedeclaredasthepreferredbidderfor
thisassignment.
Page|21

7. AppointmentofServiceProvider
7.1. AwardCriteria
Finance Department will award the Contract to the successful bidder whose proposal has been
determinedtobesubstantiallyresponsiveandhasbeendeterminedasthemostresponsivebidsas
pertheprocessoutlinedabove.
7.2. RighttoAcceptAnyProposalandToRejectAnyorAllProposal(s)
FinanceDepartmentreservestherighttoacceptorrejectanyproposal,andtoannulthetendering
process/Publicprocurementprocessandrejectallproposalsatanytimepriortoawardofcontract,
withouttherebyincurringanyliabilitytotheaffectedbidderorbiddersoranyobligationtoinform
theaffectedbidderorbiddersofthegroundsforFinanceDepartmentaction.
7.3. NotificationofAward
Priortotheexpirationofthevalidityperiod,FinanceDepartmentwillnotifythesuccessfulbidderin
writingorbyfaxoremail,thatitsproposalhasbeenaccepted.Incasethetenderingprocess/public
procurement process has not been completed within the stipulated period, Finance Department,
mayliketorequestthebidderstoextendthevalidityperiodofthebid.
Thenotificationofawardwillconstitutetheformationofthecontract.Uponthesuccessfulbidder's
furnishingofPerformanceBankGuarantee,FinanceDepartmentwillnotifyeachunsuccessfulbidder
andreturntheirEMD.
7.4. ContractFinalizationandAward
TheFinanceDepartmentshallreservetherighttonegotiatewiththebidder(s)whoseproposalhas
been ranked best value bid on the basis of Technical and Commercial Evaluation to the proposed
Project,aspertheguidanceprovidedbyCVC.Onthisbasisthedraftcontractagreementwouldbe
finalizedforaward&signing.
7.5. PerformanceGuarantee
The Finance Department will require the selected bidder to provide a Performance Bank
Guarantee,within15daysfromtheNotificationofaward,foravalueequivalentto10%ofthetotal
cost of ownership. The Performance Guarantee should be valid for a period of 5 years. The
PerformanceGuaranteeshallbekeptvalidtillcompletionoftheprojectandWarrantyperiod.The
PerformanceGuaranteeshallcontainaclaimperiodofthreemonthsfromthelastdateofvalidity.
The selected bidder shall be responsible for extending the validity date and claim period of the
Performance Guarantee as and when it is due on account of noncompletion of the project and
Warrantyperiod.Incasetheselectedbidderfailstosubmitperformanceguaranteewithinthetime
stipulated,theFinanceDepartmentatitsdiscretionmaycanceltheorderplacedontheselected
bidderwithoutgivinganynotice.FinanceDepartmentshallinvoketheperformanceguaranteein
casetheselectedServiceProviderfailstodischargetheircontractualobligationsduringtheperiod
or Finance Department incurs any loss due to Service Providers negligence in carrying out the
projectimplementationaspertheagreedterms&conditions.
7.6. SigningofContract
AftertheFinanceDepartmentnotifiesthesuccessfulbidderthatitsproposalhas beenaccepted,
Page|22

FinanceDepartmentshallenterintoacontract,incorporatingallclauses,prebidclarificationsand
theproposalofthebidderbetweenFinanceDepartmentandthesuccessfulbidder.TheDraftLegal
Agreementwillbeprovidedasaseparatedocument.
7.7. FailuretoAgreewiththeTermsandConditionsoftheRFP
FailureofthesuccessfulbiddertoagreewiththeDraftLegalAgreementandTerms&Conditionsof
theRFPshallconstitutesufficientgroundsfortheannulmentoftheaward,inwhicheventFinance
Departmentmayawardthecontracttothenextbestvaluebidderorcallfornewproposalsfrom
theinterestedbidders.In suchacase, theFinanceDepartment shallinvokethePBGofthemost
responsivebidder.
Page|23

8. TermsofReference
8.1. ScopeofWork
Thesolutionshouldbebuiltinaccordancewithbestpracticesinsimilarsituationsanddeveloped
onthebusinesslogicframeworkapplicabletothestate.Allsecurityandfinancialprocessaspects
wouldneedtocomplywiththeInformationTechnologyActandRBIguidelines.Scopeofworkfor
theassignmentcanbebrieflymentionedasunder:
TomanagetheProject&Deliveries
ToconductSystemRequirementStudy
TodevelopSolutionArchitect&Design
Todevelop/customize/configuretheSoftware
TodevelopMIS
ToperformSoftwareTesting
ToprepareDocumentation
TocooperateduringUserAcceptanceTesting
ToconductPilotImplementation
ToimpartUserTraining
ToconductPilotTesting&Rollout
ToperformChangeManagement
ToprovideAnnualMaintenanceSupport
ToprovideHelpdeskOperation
SoftwareEnhancementandSupport
ExitPlan
8.1.1. ProjectManagement
Finance Department has institutionalized Empowered Committee to provide overall
guidanceanddecidepolicylevelmatters,financialmattersandtoactasfinalbodyfor
approvingalldeliverablesrelatingtotheproject.
TheProjecteMissionTeam(PeMT)institutionalizedunderEmpoweredCommitteeto
provide overall project leadership and take full ownership of the project design,
development including transformation, change management, strategy control and
business process reengineering. Resource persons of the service provider should
closelyworkwithPeMTduringsystemstudy,softwaredevelopment,implementation
andsupportphase.
Quantity and duration of services mentioned in this scope section is based on
assumption and may vary during execution. Empowered Committee will decide to
Page|24

increaseordecreaseboththequantityanddurationofservicesthroughprojectreview
process.
Service provider shall provide project management services and technology
consultationservicesforentireprojectperiod.
The service provider shall provide required project management tools for smooth
managementoftheproject.
8.1.2. ConductingSystemRequirementStudy
IntegratedOdishaTreasuryManagementSystem(iOTMS)issuccessfullyimplemented
inOdishaandthesoftwareisupandrunninginproductionmode.FinanceDepartment
willprovideSTQCcertifiedsourcecodeandrelatedtechnicaldocumentofiOTMSasan
input to the selected service provider. The service provider shall perform a detailed
assessment of the source code to make integration and to provide maintenance
supportservicetoiOTMS.
The Service Provider shall perform a detailed assessment of the functional, technical
andoperationalrequirementssetoutintheRFP.
For the requirements listed in the RFP, Service Provider shall prepare the System
Requirement Specifications (SRS) based on the process definitions & Functional
RequirementSpecifications(FRS)documentasprovidedwiththisRFP.
It would be the responsibility of the Service Provider to identify all requirements for
theportalanddocumentitaspartoftheSRS.
AformalsignoffshouldbeobtainedfromthedesignatedofficerofPeMTfortheiFMS
Odisha Project, before proceeding with the Design, Development, Customization and
Installationofthesystems.
8.1.3. DevelopingSolutionarchitecture&Design
The Service Provider shall prepare the solution design keeping in mind the technical
requirementssuggestedinthisRFPaswellasthesignedoffSRS.ServiceProvidershall
preparethefollowingsasapartofsolutiondesigning
o SystemDesigning
o DatabaseDesigning
TheServiceProvidershalldesignthesolutionarchitecture&specificationsformeeting
the system requirement specifications finalized by the Service Provider and as
approved by the PeMT. The Solution Architecture should highlight the major
componentsofthesolutionandtheirinteractionsandtheresponsibilitiesassignedto
them,andmapittotherequirementsidentifiedintheSRS.
Additionally, with respect to this detailed system design document, the document
shouldminimallyincludethefollowing
o Designofthedetailedapplicationsystem,includingmodularstructure.
o Userinterfacedesigns
Page|25

o DatabasestructuresincludingER,DataDictionariesandDFD
o DataBackup&RecoveryStrategy;
o BusinessProcessModelsusingControlFlowDiagram,Flowcharts
TheServiceProvidershallsubmitthesolutiondesigndocumenttothedepartmentand
obtain a sign off on the design document before commencing the development/
customization/installationofthesolution.
8.1.4. ReorientationofiOTMSasperNewSolutionArchitecture
Theexistingapplicationneedtotakeadvantageofproposedsolutionarchitecturecomponentsby
Externalizingtheexistingdatabasebasedworkflowandhardcodedprocessorchestration
usingOracleSOASuitetechnologyplatform.
ExternalizingtheexistingdynamicandvolatilebusinessrulesusingOracleBusinessRules.
UseofOracleWebcentercontenttoeffectivelymanagethedigitaldocumentsandcontent.
UseofappropriateOSBsintegrationfeaturestoreplaceexistingiOTMSintegrationswith
othersystems.
PortingofinterfacestoOracleWebcenterPortal.
MigrationofdatafromexistingdatabasetonewOracle11g
8.1.5. Developing/Customizing/Integrating/ConfiguringSoftware
TheServiceProvidershallperformthesoftwaredevelopment/configurationbasedon
the functional & system requirement specifications and solution design finalized
thereof. The development/ configuration/ customization process should ensure that
thestandardsspecifiedduringthedesignphaseareadheredtoduringtheentirecycle.
The modules of iFMS should be integrated with iOTMS, WAMIS, HRMS, CPSMS, VLC
andotherrelatedsoftware.
A standard methodology shall be adopted for Software Engineering, covering the
entireSDLC(SoftwareDevelopmentLifeCycle)
ThedevelopmentfortheiFMSOdishaapplicationsystemshouldbeperformedatthe
premises of the Service Provider. The Service Provider premises should have the
followingminimumsupportinginfrastructure
o ApplicationStagingServer
o DatabaseStagingServer
o Versioncontrol&managementserver
o Developerscomputers
The iFMSOdisha application software system would consist of three components
namely,
o WebPortal
o ApplicationSoftware
o WorkflowComponent
Page|26

o IntegrationComponent.
The software solution developed as part of iFMSOdisha should support the bilingual
features.
The Service Provider shall implement workflows, within the application system, with
welldefinedbusinessrules.
iFMSOdisha must be integrated appropriately with existing iOTMS, HRMSOdisha,
WAMIS,CPSMS,VLCandotherrequiredsoftware.
Two way communication between the stakeholder entities and iFMSOdisha would
ensurethatthefollowingminimalrequirementsaretakencareoff
o Two way handshaking wherever possible so that each participating entity
knowsthestatusofdatadelivery;
o PointtoPointencryptionofthedataduringtransit;
o Digital signing and timestamping of data being sent out to the requesting
entitysoastoensurenonrepudiation;
o Sharing of information using XML as a form of structuring the data; there
wouldbeindividualschemarequirementsforeachstakeholderwithwhomthe
datawouldbeshared;theserequirementsshallbeworkedoutbytheService
Provideronacasetocasebasis;
o Web Service is a popular media for creating service oriented architecture for
sharing information with stakeholders. The department intends to adopt this
approach for all realtime interactions, but it is the discretion of the Service
Providertodecideonthemechanismofinteraction.
All expenses related to Software Development like cost of Software, Hardware and
Licenseswillbebornebytheserviceprovider.
8.1.6. DevelopingMIS
Thedepartmentintendstoretaintransactionaldataforaperiodof10yearswithinthe
live(OLTP)database.Thedatafortheperiodprevioustothe10yearretentionperiod
shouldbekeptinanaggregatedforminaseparatedatabaseschema.
iFMSOdishasystemshallprovidefacilityforgeneratingandviewingonline,realtime
projectandMISreportsfortransactionshandledduringaspecifiedperiod,transaction
densitytrendsforanyspecifiedperiodicity.
The MIS reporting system shall be an integrated system which shall provide user
friendlyreportingforpointsofaccesslikevariousofficesofthedepartmentand/or
designatedmonitoringoffice.
TheService Provider shall provide fullaccess to generate reports from the system to
thedepartmentofficialsoritsnominees.
Page|27

Apart from the regular textual and tabular form of reports, the system should also
enable generation of standard charts and graphs based on MIS data. The charts and
graphsshouldsupport2dimensionalrepresentationsaswellasmotioncharts.
Thesystemshouldsupportdrilldownanddrillthroughreports.
The system should provide capability to dynamically create filters for generating
reports. Such type of filters would be based on existing data or patterns within data
andwouldbemeanttosimplifyreportgenerationprocess.
ThesystemshouldhaveinbuiltsupportforBusinessIntelligence.ThescopeofBusiness
Intelligence has been clearly defined in the Technical Requirements section and the
biddershouldreaditthoroughlybeforequotingforthesame.
ServiceProvidershallcreateanOLAPsystemwithiniFMSOdishaapplicationsoftware
which shall provide a facility to perform historical analysis over backed up as well as
livedata.
8.1.7. PerformingSoftwareTesting
TheServiceProvidershallconductitstestingprocessaspertheQualityAssurancePlan
preparedandprovidedbyit.
Theobjectiveoftestingistoensurethattheentiresystemintotality,whicharepartof
this project, perform as per the objectives laid down in this RFP. The objectives will
havethefollowingminimaldimensions.
o Functional
o Security
o Performance
TheServiceProvidershalldesigntheTestingstrategy,TestCasesandconducttesting
ofvariouscomponentsofthesoftwaredeveloped/customized/configured.
TheServiceProvidershallsharethestandardsfollowedwhileperformingthetestingas
wellasthetestingstrategyandthetestcaseswiththedepartment.
iFMSOdishaProjectwillhavetoundergocomprehensivetestingandshouldminimally
include Unit Testing, System Testing, Integration Testing, Performance Testing, and
Load&Stresstesting.
TheServiceProvidershouldpreservethetestcaseresultsandshouldmakeavailableto
thedepartment.
The Service Provider shall perform testing of the application software from actual
environments of subtreasuries located at remote locations. This testing should be
performedaspartofperformancetesting.
TheselectedServiceProviderisexpectedtoprovidetestingtoolsandtechnologiesto
conductthesame.SametoolsarealsobeusedbythePeMT.
ThetestingofiFMSOdishasystemshallincludeallofthefollowingcomponentsofthe
project
Page|28

o WebPortal
o ApplicationSoftware&Database
o BudgetDecisionSupportSystem(BDSS)asBI&MIS
o Treasury Integration Mechanism for allowing integration between external
entitiesandtheiOTMSapplicationsystem.
8.1.8. PreparingDocumentation
The Service Provider shall prepare/ update the documents including the following
minimalsetof
o SoftwareRequirementSpecification
o DetailedDesign
o ChangeManagementPlan
o TrainingPlan
o TestCases&Results
o UserManuals
o Trainingmanuals
o OperationsandMaintenanceManual
o AdministratorManual
o SecurityPolicy,
Anupdatedandlatestcopyofthesedocumentshastobehandedoverduringthetime
ofexit.
TheServiceProvidershallobtainthesignofffromthedepartmentoritsnomineefor
all the documents submitted for this Project and shall make necessary changes as
recommendedbyPeMTbeforesubmittingthefinalversionofthedocuments.
8.1.9. SupportingUserAcceptanceTesting
There will be an Operational Testing Group (OTG) within PeMT comprising technical
consultants and users of all level from different stakeholder institutions to perform
UserAcceptanceTesting(UAT)oftheentireiFMSOdishasystem.Thedepartmentwill
be responsible for providing final acceptance sign off, after consulting the OTG, who
shall represent the department in reviewing the deliverables provided by the Service
Provider.
TheUATwillbeinitiatedfromthestagewhenthefirstphaseofapplicationsoftware
would be delivered by the Service Provider and would conclude till after golive. The
reviewwillfocusonthefollowing
o TheOTGteamwillverifyandreviewthedeliverables.Thereviewwillfocuson
completenessofthedeliverables;
o Thecomplianceofthedeliverablestobestpracticesandstandards.
Page|29

o ProcessAuditThisauditwillfocusoncheckingtheprocessesbeingfollowed
while preparing the deliverables. The processes will be evaluated against the
standardsspecifiedbytheServiceProvider.
o Implementation Audit Implementation audit will focus on reviewing the
implemented system. It will verify the performance of the system, functional
compliance,securitycomplianceandadherencetoSLA.
Acceptance criteria for the iFMSOdisha Project would be laid down by the finance
departmentafterreviewingtheSRSprovidedbytheServiceProvider.Theacceptance
criteria would be provided to the Service Provider before the development
commences.TheacceptanceofiFMSOdishawouldbeessentialbeforegolive.
ServiceProvidershallprovideandensureallnecessarysupporttothedepartmentorto
anythirdpartyconductingtheAcceptanceTestingincludingsharingnecessaryproject
documentation,sourcecode,andsystemsdesigned&developed,testingstrategy,test
casesdevelopedfortheproject,testresultsetc.
The Finance department will undertake an exercise of Testing, Acceptance and
Approval of the iFMSOdisha system through a OTG, as soon as the Service Provider
declares the system ready for this purpose before GoLive. Service Provider shall
coordinatewiththedepartmentand/ortheOTGforperformingtheacceptancetesting
andcertification.
8.1.10. ConductingPilot
The Service Provider shall carry out the pilot of the New Modules at the locations
identifiedbythedepartment.
ThepilotwillbecarriedoutinFinanceDepartment,ControllerofAccountsOffice,one
districttreasury(DT)andsubtreasuriescomingundertheDT.
Pilotshallbecarriedoutintheconnectedenvironment.
TheServiceProvidershalladdresstheissues/fixbugsidentifiedduringthepilotphase
beforetherollout.
8.1.11. OnlineHelpSystem
The Service Provider shall provide required tools to author and develop the online
contextsensitivehelpsystemandprovideviewingfacilitytotheuser.
Service Provider shall designand developcontextsensitivehelpsystem on operation
manual,usermanual(enduser&technicaluser),andcomputerbasedtutorials(CBT)
ontheapplicationformultiplelevelofusersinconsultationwithFinanceDepartment.
8.1.12. Training
TheServiceProvidershalldrawupatrainingplaninlinewiththeoverallprojectplan.
Thetrainingsshallbeprovidedatthedepartmentpremisesoranyotherpremises,as
fixedbythedepartmentwithintheState.
Page|30

The Service Provider shall provide an interface for all users of the iFMSOdisha
applicationsystemforsubmittingqueriestothehelpdesk.Thissystemwouldbeused
bytheServiceProvidertorespondtosuchquerieswithappropriateclarifications.This
interfaceshouldsupportbothcommunicationinOdiaandEnglish.
TheServiceProvidermustimparttrainingtoallthetreasurystaff,otherGovernment
department staffs like DDOs, PL and Divisional Operators (including finance
department) to make them well conversant with the functionalities, features and
processesbuiltintheiFMSOdishasystem.Thisisaimedtoensuresmoothoperations
enabledthroughiFMSOdisha.TheServiceProvidershalltrainallsuchemployeesand
providerelevanttrainingmaterialstothem.Thetrainingpedagogywillbedesignedto
imparthandsonexperiencewithadequateusageofcasesandscenariostotheextent
feasible. The number of such users and duration of the Training Period is provided
below:
UserbaseforiFMSOdishaApplicationSystem
Stakeholder/User NoofUser Minnoof
Offices EndUsers
Treasuries 165 1100
DirectorateofTreasuries&Accounts 1 25
ControllerofAccounts 1 25
AG 1 5
AdministrativeDepartments 40 100
ControllingOfficers 171 350
DrawingDisbursementOfficers 6,500 13000
Divisions(CDDOs) 370 750
P.L.operators 1085 2000
Theidentifiedstaffswouldbeprovidedwithhandsontrainingonallmodulesrelated
tothedaytodayoperationsoftheiFMSOdishaSystem.
Trainingcontentwillfocusonscenariosandcasestudieswithrespecttoeachtypeof
transaction with the purpose of giving a realistic approach to the trainee on how to
handle a particular case. Also, emphasis would be on giving as much handson
experience as required to make the trainees fully conversant and able to work
effortlesslyontheapplication.
The service provider shall provide computer based tutorials (CBT) on the application
formultiplelevelsofusersinconsultationwithFinanceDepartment.
The Service Provider shall prepare a team of iFMSOdisha champions from the staff
membersofthetreasurydepartmentaswellasfromvariousotherstakeholders.These
trainerswillbebasedoutofeach individualtreasuryanddepartmentsandwouldbe
responsible for guiding iFMSOdisha users in their respective locations, on using the
applicationsystem.
Page|31

Finance Department will provide the all necessary infrastructure to organize the
trainingprogram.FinanceDepartmentwillprovideoftrainingkit(designedbyservice
provider)toalltheparticipants.
8.1.13. RolloutacrossState
Rollout will be done in three phases, where following modules will be implemented
phasewiseacrossalltheDistrictTreasuries,SubTreasuriesanddifferentdepartments
asmentionedatsection8.5(FunctionalComponent)
IntegrationofdepartmentswiththeiFMSOdishasystemwouldbeaseparateactivity
which would be performed in two stages of pregolive (parallel to the rollout) and
postgolive.
Serviceprovidershouldprovideminimum38implementationengineersfor18months
implementation period. These implementation engineers will be placed at district
treasuriesandatspecialtreasuries.
If required, empowered committee may exclude any/some module(s) from the
proposed module list. Cost of rollout (Form18) may be reduced accordingly.
Calculationofreducedamountwillbedoneaccordingtothereducedimplementation
effortwithrespecttonoofunitoffices.
Service provider will submit monthly completion report of implementation service to
thedepartment.Thisreportmustincludesupportingdocumentsoncompleteadaption
fromeachunitofficesdulyapprovedbyPeMT.
Service provider can claim implementation cost on the basis of monthly completion
reports,aftercompletionofeachphase.
8.1.14. Maintenance&SupportServices
Any subsequent changes to the application are incorporated in the Application
Repository on an incremental basis, after going through the prescribed approval
processes. All change requests should be initiated by the Finance Department,
GovernmentofOdisha.
Any changes to the application required to fix any existing bug, enhance the user
interfaces, develop report programs or to improve performance or to cover security
gapswithinagreedFunctionalRequirementSpecificationarecoveredunderSoftware
MaintenanceandSupportServices(Form20)ofFinancialProposal.
SoftwareMaintenanceandSupportServiceswillbestartedaftersuccessfulcompletion
of PhaseI implementation by the service provider. The same service will also be
includedforexistingiOTMS.
Service Provider will provide minimum 7 Software Developers and DBA at state level
for a period of 45 months. Selected service provider will take charge from existing
serviceproviderandwillalsoprovidesupportforexistingiOTMS.Afterdeliveryoffirst
phasemodulessupportserviceswillbeprovidedforrest45monthsbothforexisting
iOTMSandiFMSOdisha.
Page|32

Such changes shall first be hosted in an application staging environment, tested for
consistency,integrityandperformancebytheApplicationAdministratoroftheService
Provider.ThereuponarequestshallbepreferredtotheApplicationAdministrator(s)of
the Department, to permit the proposed changes with Impact analysis report, with
clearreasonsnecessitatingthechange.
TheactionsoftheapplicationadministratoroftheServiceProvidershallbekeptasfew
and infrequent as possible. To this end, the enhancements and changes proposed to
the application are planned sufficiently in advance, to the extent possible, bunched
togetherandimplementedatprespecifiedintervals.
The roles of different personnel responsible for designing, coding, accepting the
changes and authorizing the changes to be carried out into the production
environmentshallbeclearlydefinedbytheServiceProvider.
Service Provider shall also provide complete maintenance support for all the
proposed iFMSOdisha Solution components as outlined in this RFP and solution
components of iOTMS for approximately 45 Monthsfromthedate ofcompletionof
firstphaseimplementation.
TheoperationsshallcovertheFinanceDepartmentofficeatSecretariatBhubaneswar
and all offices related to Directorate of Treasuries & Inspection. They are 165
Treasuries,40AdministrativeDepartments,171ControllingOfficers,6,500DDOs,370
Divisions (CDDOs), 1085 P.L. operators. Support will be provided both online and
offline from the Central Location, if required, support may also be provided at the
DistrictorSubDivisionlevel.
ForthepurposesofthisRFP,prerequisitesforGoLiveareasfollows:
o TheiFMSOdishaiscompletelyoperationalaspertherequirementsinthisRFP
after successful completion of the pilot and full rollout. All the acceptance
testsaresuccessfullyconcludedasperthesatisfactionofthedepartment.
o The system is certified by OTG, wherever applicable, in accordance with the
requirementsofthisRFP.
The same operations shall be extended to the new treasury offices which may be
openedbythedepartmentduringthecontractperiod.
IfnewtreasuryofficesarecreatedtheServiceProvidershallprovideformanpowerto
meetthedemandatcostsquotedinthecommercialproposalsubmittedinresponseto
thisRFPoratexistingmarketrates,whicheverislesser.
Withrespecttothefunctionsandactivitiestobeundertakenbythevendorunderthe
scope of this project, no outsourcing will be allowed for critical roles such as project
manager/Coordinator,TechnicalLeader,systemadministrator,databaseadministrator
andapplicationadministrator.Allthepersonneldeployedduringthecontractperiodat
thedatacentreandbusinesscontinuitycentre/disasterrecoverycentrehavetobefull
timeemployeesoftheServiceProvider.
Page|33

Service provider will submit monthly completion report on software maintenance &
supportservicestothedepartment.ThisreportmustbeapprovedbyPeMT.
Service provider can claim software maintenance & support service cost as per the
actualconsumptionofserviceonquarterlybasis.
8.1.15. HelpDeskOperation
The Service Provider would be required to provide Helpdesk services to enable effective
support to the internal and external users for operational and technical issues regarding the
iFMSOdishaapplicationsoftware.Allthecostwillbebournbytheserviceprovider.
The SI will start the helpdesk service after successful completion of User acceptance
Testing(UAT)andstartingofPhaseIrollout.
TheServiceProvidershallprovideatleastthefollowingservices
o Provisionandsupervisionofpersonnelforthehelpdesk.
o Service provider should provide 4 helpdesk support resource person at state
levelfor51months.
o All calls will be assigned a ticket number and the number will be made
availabletotheuser.
o Helpdesk shall provide support for technical queries and other software
relatedissuesarisingduringdaytodayoperations
o Thedepartmentuser/operatorshouldbeabletologanytechnicalissuerelated
totheapplicationthroughtheexistingMANTIScallloggingsystemalso.
o Physicalspaceforthehelpdeskwillbeprovidedbythedepartment.Required
infrastructurewillbeprovidedbytheServiceProvider.
o Service Provider will adhere to the agreed service level with respect to the
resolutionofissuesatvariouslevels.
Allcomplaints/grievancesofuserswillbemaintainedandfollowedupforresolution
andanescalationmatrixtobedevelopedforanydelayinresolution.
TheServiceProvidershouldcreateanIVRSsystemforprovidingtheinformationabout
thestatusoftheirgrievanceafterperformingnecessaryidentification.TheIVRSsystem
shouldprovisionforthefollowing:
o The IVR system shall be available via the helpdesk number, to monitor the
status of the call logged by the users. A dualtone multifrequency (DTMF)
signalling menu service must be available for users to retrieve information
fromtheservice.
o TheserviceshallbeaccessibleinEnglish,andOriya.
o Themenustructureshallprovidecallerswithtouchtoneshortcutsthatcanbe
used in sequence, which will allow the knowledgeable users to access
information more quickly, without having to drill down through the menu
structurewitheverycall.
Page|34

The Service Provider shall provide the following helpdesk performance monitoring
reports.
o Callsperweek,monthorotherperiod;
o Numericandgraphicalrepresentationofcallvolume;
o Calls for each interaction tracked by type (calls for information on specific
service,callsforspecificenquiries);
o Numberofdroppedcallsafteranswering,including:Callsthatendedwhileon
hold,indicatingthatthecallerhungup;
o Call that ended due to entry errors using the automated system, indicating
difficultyinusingthesystem;
Serviceproviderwillsubmitmonthlyreportonhelpdeskoperationtothedepartment.
ThisreportmustbeapprovedbyPeMT.
Serviceprovidercanclaimhelpdeskoperationcostaspertheactualconsumptionof
serviceonquarterlybasis.
8.1.16. SoftwareEnhancementServices
Duration of the project implementation is planned to be 5 years. Looking into the length of the
projectimplementationperioditisveryusualtofindchangesinbusinesslogicframeworks.Insuch
scenarios there may be a need of modification of the software modules beyond Functional
Requirement Specification (FRS) document mentioned in this RFP. It may also be required to
developnewsoftwaremodulesbeyondthecoverageofFunctionalRequirementSpecification(FRS)
document.InabovementionedscenariostheEmpoweredCommitteeofFinanceDepartmentmay
directtotakeup such assignments. Theservice provider is supposed to preparethe detail effort
estimationfordevelopmentandimplementationofsuchassignmentsandsubmittheproposalto
PeMTforapproval.On approvalofPeMT serviceprovidershalldelivertheservices andraisethe
claimasper actual accordingtothe(Form21)ofpriceschedule.5000mandaysareprovisioned
forsuchadditionalsoftwareenhancementservicesspreadover3.5years.Theserviceprovidercan
raiseclaimsunderthisheadasperactualconsumptionofservicedulyapprovedbyPeMT.
8.1.17. DataCenterManagement
The data centre for iFMSOdisha will be housed at State Data Center of Government of Odisha.
Servers and networking equipment will be procured by Finance Department through a separate
procurementprocessbyengagingaSystemIntegrator(SI).
The service provider of this assignment will take responsibility to coordinate with the System
Integrator (SI) to ensure correct delivery and installation of the servers, networking and other
equipment.
The service provider of this assignment shall be responsible for optimum performance tuning of
the server components to ensure smooth functioning of iFMSOdisha. The service provider shall
coordinate with the System Integrator to resolve any hardware and networking issues to ensure
uninterruptedservicesprovisiontotheusers.
Page|35

8.1.18. ExitPlan
The selected service provider will provide systematic exit plan and conduct proper knowledge
transfer process to handover operations to PeMT before project closure. IT resource persons of
PeMT will work closely with resource persons of service provider at test environment and
production data center. The service provider will ensure capacity building of the IT resource
personsofPeMTonmaintenanceofsoftwareandmaintenanceofdatacenter.
8.2. SuggestedBestPractices
Design of the system would be the responsibility of the service provider. However view to learn
from past experiences in this area, it is highly recommended that the service provider study the
existingbestpracticecasesofintegratedFinanceManagementSystemofotherstategovernments
inthecountry.Anindicativelistofgenericbestpracticestobefollowedisgivenbelowtogivethe
serviceproviderageneralideaofwhatPRDexpectstoseeinthesystem.
8.2.1. ArchitectureStyle
IFMSOdishasolutionisenvisionedonthepremisethatitwillleveragebestITpractices,guidelines
andstandards.Toensurethesame,thefollowingarchitecturestylesaredefinedasbestpractice
guidelines that must be followed, to the least, while architecting, designing and development of
thesolution.
8.2.1.1. Layered
Layered architecture focuses on the grouping of related functionality within an application into
distinct layers that are stacked vertically on top of each other. Functionality within each layer is
relatedbyacommonroleorresponsibility.Communicationbetweenlayersisexplicitandloosely
coupled. With strict layering, components in one layer can interact only with components in the
same layer or with components from the layer directly below it. More relaxed layering allows
componentsinalayertointeractwithcomponentsinthesamelayerorwithcomponentsinany
lower layer. iFMSOdisha solution should be designed and developed using the layered style by
identifying treasury functional layers, and business components and services in each layer. The
benefitsenvisagedbyusingthisarchitecturetypeare
Loose Coupling Each individual layer will have specific tasks and communication
betweeneachlayerwillbebasedonabstractionandevents.
High Cohesion High level of cohesion within the layers by ensuring welldefined
responsibility boundaries for each layer, and ensuring that each layer contains
functionalitydirectlyrelatedtothetasksofthatlayer.
ClearlydefinedfunctionallayersTheseparationbetweenfunctionalityineachlayeris
clear.Upperlayerssuchasthepresentationlayersendcommandstolowerlayers,such
as the service and business layers, and may react to events in these layers, allowing
datatoflowbothupanddownbetweenthelayers.
8.2.1.2. Ntier
EachlayerintheTreasurysystemwillbedeployedoverphysicallyseparateserverssoastoensure
flexibilityindeploymentandmanagement.Thebenefitsenvisagedbyusingthisarchitecturetype
are
Page|36

Maintainability Because each tier is independent of the other tiers, updates or
changescanbecarriedoutwithoutaffectingtheapplicationasawhole.
Scalability Because tiers are based on the deployment of layers, scaling out an
applicationisreasonablystraightforward.
Flexibility Because each tier can be managed or scaled independently, flexibility is
increased.
Availability Applications can exploit the modular architecture of enabling systems
usingeasilyscalablecomponents,whichincreasesavailability.
8.2.1.3. ServiceOriented
Serviceorientedarchitecture(SOA)isenvisagedtoenableapplicationfunctionalitytobeprovided
asasetofservices,andthecreationofapplicationsthatmakeuseofsoftwareservices.Themain
benefitsofthisarchitecturalstyleare
Location Transparency: Since scalability is a key requirement, each business

componentservicesdeployedcanbescaledoutandmovedacrossmultiplemachines
without impacting clients as they bind to a specific service interface and use a well
publishedendpointreference.
ImprovedAgility:Isolatinglonglastingcapabilitiesindifferentservicesawayfrommore
volatile business process layer is first step in increasing agility. Policy changes can be
independentlyimplementedfromruleengineinruleserviceswhichcapabilityservices
andworkflowsusetoallowforfasterorganicchanges.
Better Abstraction: Business processes and higher layer of services work with the
service interfaces of the services whereas whether the service implementation
component can be replaced, migrated, rented, or changed without impacting the
clients.
Interoperability: With usage of open Standards and availability of discovery

environmentprovidedthroughSOA,differentservicesgetintrinsicallyintegratedwith
each other to provide Service integration architecture that leads to better intrinsic
interoperability.
Functional Rationalization and Reuse: Services can be granular in order to provide

specific functionality, rather than duplicating the functionality in number of
applications,whichwillremoveduplication.
8.2.2. ArchitectureConstraints
Theapplicationproposedhastoadheretovariousrequirementconstraintswhichareessentialfor
addressingtheobjectivesofthedepartment,theyarenamelythefollowing:
Webbased single unified interface (available over internet as well as intranet) The
iFMSOdishaapplicationshouldbeaccessiblebybothinternalusersaswellasexternal
users (Citizens or Businesses). The single system should be available to two types of
users, namely, those who access using departments own WAN or SWAN for the
departments own users and those who access using Internet like the DDOs,
Departments,Public,etc.Theaimisthatboththesetypesofusersshouldbeableto
Page|37

seamlessly work together on a single activity which may require information sharing
withouteachbeingaskedtoperformanyswitchingofplatformsorapplications.
Tobecentrallydeployedwithasingledatasource:TheiFMSOdishasolutionshouldbe
centrallydeployedanditsdatashouldbehostedcentrallytoprovideanintegratedand
holistic view of complete treasury functions so that it can centrally monitored and
controlledeffectively.
Securemultifactoraccesstoapplicationinterfaces:TheiFMSOdishainterfaceshould
be built in such a way that it provides secure (multifactor using PKI infrastructure
wherever necessary) access to its interface to appropriately authenticated and
authorized users. The system should guarantee of data delivery at all times, without
fail, so sufficient reliability and information integrity related tactics should be
engineeredinthesolutiontoensurethesame.
Role based authorization within the system: The Department runs its day to day
functions using various roles assigned to individuals. These roles have various
capabilities and clearly delineate responsibilities of individuals. The upcoming system
should enable support for replicating the manual process of role assignment and
delegationwithinitself.Thesystemshouldthusbebuiltinamannerthatrolescanbe
createdormodifiedordeleted,whileresponsibilitiescanbeassignedanddeassigned
tosuchroles.
Open standard based solution technology standards to be used: As much as possible

thesolutionshouldbebuiltusingopenand/orindustrystandardtechnologyplatform
andstandardstoensureinteroperabilityandportabilitywithinandbeyond.
Useofworkflowbasedprocessing:Theproposed systemwillbe usedbydepartment

officialsaspartoftheirdaytodayworkandalsoaspartofaprocesswhereinmultiple
individuals will be working simultaneously over a single transaction. Such a system
should be workflow driven, wherein clear delineation of individuals roles should be
maintained,suchthatnotwopersonsshouldbeabletoworkonasingletransaction
simultaneously.Furtherappropriatealerts&remindersshouldbegeneratedforeach
individual to complete his or her pending task. The workflow should be configurable
wherein individuals roles and position in the workflow can be modified, removed or
inserted.
Capabilitytoperformtaskmanagementasaseparateactivity:Theapplicationshould
segregatethe tasks basedupon the human interventions required. Tasksthatdonot
require human interventions, such as sending emails, alerts, printing, report
generation,scheduledactivities,etc,shouldbemanagedusingatasklayer.Tasklayer
willbeautomationdrivenwithoutanyinvolvementofhumaninterfaces.
Use of business rules framework: The policies and rules governing various processes
within the Treasury system can undergo frequent changes. As such it is proposed to
implement Business rules framework within the system, such that process requiring
frequent changes can be modified without requiring any patches to be deployed or
requiringanytypeofharddeploymentwithinthesystemwhichrequiresdowntime.
Page|38

8.2.3. QualityofService
The quality attributes define the areas where the application has to prove its value. The overall
qualitiesoftheproposedsystemwhenconsideredasawhole,shouldinclude,butnotlimitedto,
thefollowing:
Supportability,meaning,thecapabilityofsupportingtheiFMSOdishasystemoverits
whole product life. This implies not only satisfying any necessary needs or
requirements, but also the provision of equipment, support infrastructure, additional
software, facilities, manpower, or any other resource required to maintain the
softwareoperationallyandcapableofsatisfyingitsfunction.Thebiddersareexpected
tosuggestmechanismstobeadoptedbythem,includingprocessestobeadoptedas
wellastechnologiestobedeployed,soastoensurethattheiFMSOdishasolutionhas
ahigherdegreeofsupportability.
Testability, meaning, the degree to which a software artifact (i.e. a software system,
softwaremodule,requirementsordesigndocument)partoftheiFMSOdishasystem
supports testing in a given test context. The bidder should ensure that as part of its
technical proposal it highlights the mechanisms to be followed in ensuring the high
testabilitystandardsoftheiFMSOdishaapplicationsystem.
Availability, meaning, the systems capability to ensure higher uptime and lesser
downtime.Treasurysystemdependsuponuninterruptedperformanceofitssoftware
systems to support its activities and any unplanned downtime of such systems can
result in significant costs and negative publicity. The bidder, as part of its technical
proposal,shouldclearlyspecifythemechanismtoreduceMeantimebetweenfailures
MTBF. The requirement for high level of availability can be measured at every point
includingsoftware,hardwareandnetwork.
Interoperability,meaning,theabilityofthesystemtoworkwithothersystemswithout
special effort from the user is a key factor within the department. The proposed
application system needs to work in a heterogeneous environment and needs to
ensurethatallthesystemspartofthisheterogeneousenvironmentshouldbeableto
shareinformationinawaywhichitiscapabletounderstand.
Manageability,meaning,proposedapplicationsoftwareshouldbedesignedtonotonly
service the end users of the department, but also the software operators (IT
departmentsormanagedSIs)workingforthedepartment.Applicationsoftwarehasto
be designed with functionality to simplify the management of the software by
operationsteams.Thetechnicalproposalofthebiddershouldensurethattheypresent
amechanismtoprovideasophisticatedlevelofmanageability.
Performance has many dimensions; while adherence to functional & nonfunctional

requirements is one major dimension for measuring performance, another major
dimension would be the responsiveness of the system. While responsiveness of the
system can be measured against various factors, namely, end users or against
scenariosoreventssuchasincreaseinpeakhourtraffic.Thebiddershouldaddressthe
Page|39

concerns of the department using its technical architecture and sizing documents on
howitintendstoaddresstheperformancerequirementsoftheiFMSOdishasystem.
Reliability, meaning, the probability of failurefree system operation for a specified

periodoftimeinaspecifiedenvironment.TheTreasurysystemneedstohaveahuge
componentofreliabilitywhereinitshouldensurethatacertainlevelofperformance
would be delivered under any and every circumstance. It is for the selected Service
Providertoidentifythecircumstancesandperformadequatesizingformeetingthose.
Hereitshouldalsobenotedthatreliabilityofapplicationinmanagingthedatasecurity
andtransactionsbothbetweenagenciesaswellaswithintheiFMSOdishasystem,is
anessentialcomponentoftheiFMSOdishaapplicationsystem.
ScalabilityisadesirablepropertyoftheiFMSOdishasystem,including,itsapplications,
servers,network,databasesoraprocess,whichindicatesitsabilitytohandlegrowing
amountsofwork.Thesystemshouldprovidefordynamicaswellaspassivescalability.
The scalability should be both vertical (scaling up), i.e. adding more resources to the
system, as well as horizontal (scaling out), i.e. adding more nodes to the system. In
Treasuryparlanceitreferstothefollowing
o Capabilityofaddingmoreuserstothesystem
o Capabilitytoaddmoreprocesseswithinthesystem
o Capabilitytoaddstepstoaprocesswithinthesystem
o Capabilitytoaddmorephysicaltierstothesystem
o Capabilitytoenhancethehardwarecapacity
Security, meaning, protection of information and property from theft, corruption, or
naturaldisaster,whileallowingtheinformationandpropertytoremainaccessibleand
productive to its intended users. The term system security means the collective
processes and mechanisms by which sensitive and valuable information within the
Treasury system owned by the Government and its services are protected from
publication, tampering or collapse by unauthorized activities or untrustworthy
individuals and unplanned events respectively. This would include payment
authorizationprocesses,using3rdpartypaymentgateways,aswell.
Integritycanbedefinedinthreeterms,namely,
o SystemIntegrityThestatethatexistswhenthereiscompleteassurancethat
under all conditions the iFMSOdisha IT system is based on the logical
correctnessandreliabilityoftheoperatingsystem,thelogicalcompletenessof
the hardware and software that implement the protection mechanisms, and
dataintegrity.
o Application integrity A critical requirement from iFMSOdisha application is
toensurethatanyoperationsitperformsareperformedcorrectly.
o DataintegrityDataintegrityisdatathathasacompleteorwholestructure.
All characteristics of the data, within the iFMSOdisha database, including
business rules, rules for how pieces of iFMSOdisha data relate dates,
definitions and lineage must be correct for ensuring integrity of iFMSOdisha
database.
Flexibility,meaning,theabilityofiFMSOdishasystemincludingitshardwareaswellas
thesoftwaretochangeeasilyi.e.theeasewithwhichasystemorcomponentcanbe
modified for use in applications or environments other than those for which it was
Page|40

specificallydesignedfor.Byincorporatingconfigurableworkflowtechnology,business
rules engine and intelligent agent techniques into information systems, iFMSOdisha
software can be made more robust, more cost effective to maintain, and easier to
change.
Maintainability, meaning, the probability of performing a successful repair action

within a given time. Mean time to repair, or MTTR, is a common measure of the
maintainabilityofasystem.Thebidder,aspartofitstechnicalproposal,shouldclearly
specifythemechanismtoreduceMTTR.
Usability is an important criterion for the proposed application to adhere to. The
elegance and clarity with which the interaction between the user and the treasury
systemshouldtakeplaceisanimportantandasubjectivefactorcriticaltothesuccess
oftheapplication.Theusabilityasafactorwillbeevaluatedovertwocriteria,namely,
o MoreefficienttouseItshouldtakelesstimetoaccomplishaparticulartask
o EasiertolearnOperationcanbelearnedbyobservingtheobject
o Easeofavailabilityofhelpandfrequentlyaskedquestionsaspertherelevance
ofthesubjectortopic
o Alertsandpopupmessagesforguidingtheuser
o Sophisticationinerrorhandling
o Capabilitytouserstocustomizethescreensandfeatureswithinthesystem.
8.2.4. Integration
8.2.4.1. IntegrationArchitecture
The integration architecture introduces the concept of Treasury Service Bus (TSB). TSB is a layer
whichcombinesalltheinternalandexternalservicesintoasinglefunctioningentityanddelivers
them through a single channel. Technically it is a set of services designed using service oriented
architecture(SOA)approachtoensureinteroperabilitybetweeniFMSOdishaandothersystems.
iFMSOdisha WebServices
TreasuryServiceBus
HTTP/HTTPS SOAPoverHTTPS FTP/SFTP
Application ExternalSystem
Theintegrationarchitectureunderlinestherequirements fromtheproposedsystem forensuring

informationexchanges.Ittriestoprojectapossiblescenarioofdataexchangeandthepossiblesets
ofsolutionformanagingthesetypesofdataexchanges.
The architecture keeps in mind the level of preparedness of various participating entities that
would be involved in the work of data sharing and is thus an indicative representation of the
possiblescenarios.ThedepartmentsandbanksintegratingwiththeiFMSOdishainitiativemaybe
capableofsharinginformationthroughtwomechanisms:
Page|41

1. Realtime
2. Batchwise
TwowayscommunicationbetweenthestakeholderentitiesandiFMSOdishawouldbeconducted
using both Intranets as well as Extranet and would ensure that the following requirements are
takencareof
3. Twowayhandshakingsothateachparticipatingentityknowsthestatusofdatadelivery;
thiswouldbedonebyimplementingacustomprotocolonacasetocasebasis
4. PointtoPointencryptionofthedataduringtransit
5. Digitalsigningandtimestampingofdatabeingsentouttotherequestingentitysoasto
ensurenonrepudiation

TheTSBlayeristobeimplementedusingOracleServiceBus,whichispartofOracleSOASuite11g.
Oracle Service Bus supports heterogeneity and can reliably connect any service by leveraging
standards.
8.2.4.2. IntegrationGuidelines
The following integration related guidelines should be following while designing and developing
theiFMSOdishainterfacestoexternalsystems
Use of open or industry standard based message exchange protocols to ensure

interoperabilitybetweenparticipatingsystems
AsmuchaspossibleuseofportabledataandexchangeprotocolslikeXMLandWebService
Ensureguaranteeddeliveryofmessagesbycapturingtheacknowledgmentorconfirmation
ofdeliveryandreceiptofmessages.
Ensureintegrityofdataintransitthroughpublicnetwork
Propererrorhandlingmechanismandmessageresendcapability
Abilitytoviewfailedmessagesandreasonfortheirfailure
EnsureproperAuditabilityandaccountabilityofdataexchangebetweeniFMSOdishaand
othersystems
8.2.5. Security
It is required to build a complete audit trail of all transactions (add, edit and delete) using
transaction log reports, so that errors in data intentional or otherwise can be traced and
reversed. Each level of security has a cost associated to it. For each function choose a level of
securitywhichiscommensuratewiththevaluetothatfunctionfortheorganizationandsufficient
to contain its risk to an acceptable level. Access Controls must be provided to ensure that the
databases are not tampered or modified by the system operators. Implement data security to
allowforchangesintechnologyandbusinessneeds.
Page|42

8.2.5.1. SecurityArchitecture

G2CUser G2GUser G2BSystems

Identity Access Audit
SSO PKI
Management Management Log

iFMSOdisha
8.2.5.2. SecurityGuidelines
Internal Users (Department Users / Operators) should not be able to login to the
application,withoutprovidinglogincredentialsanddigitalcertificate
Externalusers(usersoutsidethedepartment)shouldbegivenaccesstothesystemviathe
proposedDMZonly.
Access for internal users should be secure through LDAP and appropriate authentication
services.
ThereshouldbeasinglesignonintotheentireiFMSOdishawhereinoneidentitywouldbe
used to login into a PC and the same identity can be used for working within the
application,databaseandothersoftwareandhardwarepartoftheiFMSOdisha.
EverycomponentoftheiFMSOdisha,includingthecomputers,printers,users,application
and any other peripheral equipment should have an identity within the directory server
andaccesstowhichwouldbegovernedbythepoliciesdefinedintheserveritself.
Databaseserveraccessshallbeprovidedthroughappropriate accesscontrol mechanism.

User groups would be created at database server for allowing access to various data
repository.
Users should be granted access to information, data, devices, processes/daemons, audit

files and software on a "need to know" basis. Access will be restricted according to the
usersrequirementtoread,writeorexecutedataorsoftwareonthebasisofleastprivilege
toachievethedesiredfunction.Theproposedsolutionmustallowcontrollingactionsand
accesstoresourcesofallusersincludingprivilegedaccountssuchasroot/administrator.
Thereshouldnotbeanymechanismtodeletedataorinformation.Allactivitiesofdeletion
shouldleadtodatabeingmovedfromthemainplacetoasecondaryplaceearmarkedfor
storingdeleteddata.Undernocircumstancesdatashouldbeexpunged.
ThesystemshouldsupportRolebasedAdministrationandRoleBased&RuleBasedUser
Provisioning.
Shouldhaveanembeddedworkflowwhichwouldhelpinautomatingroutinetedioustasks
likeapprovalprocesses.
Page|43

The proposed solution must provide the ability to designate specific users as
Administrators, Auditors, and Password Managers etc with appropriate rights. The
proposedsolutionmustalsoprovidetheabilitytodesignatespecificusersasSubordinate
orGroupAdministrators,tomanageusersandfilepermissionsfortheirGroup.
All systems used must have the ability to perform password management functions
including controlled password expirations, forced password change with optional grace
logins, minimum password lengths (eight characters), alphanumeric password standards,
passwordhistorylogging,anduserlockoutfromfailedloginattempts.
All access violation attempts (user and resource authentication) will be logged and
reported.
There will be a onetoone relationship between user Ids and individuals. Access to
computingresources(e.g. files, applications,anddatabases)viashareduser Idsisstrictly
prohibited.
Capability to access the data content of the database from an interface other than the
applicationinterfaceshouldbeprohibited.
ApplicationuserAuthentication&authorizationrelatedtransactionsshouldbeencrypted.
Application should restrict to authenticate a user whose password has expired until the
userchangestheexpiredpassword.
The application should display an appropriate message upon successful login or and a
warningafterfailedloginattempt.
Theapplicationshouldenablethecreationofdifferentusergroups,andtheassignmentof
differentprivilegestoeachgroup.
Theapplicationshouldsupportrolebasedaccesscontroltoenforceseparationofduties.
The application should display the last login status (successful/unsuccessful, time) to the
user.
In case the system is being accessed by other systems / web services / interfaces, the
systemshouldperformdueauthentication.
It is preferred that no direct access to the database is provided to any external agency
unlessrequiredandapprovedbythedepartment.
Incaseofdataupload(e.g.uploadofaXMLfile/Excelfile/ASCIIfile)ordatatransferthe
applicationshallhavecontrolssuchasdatatotaling/controltotaling/checksumstoensure
thatthedatatransferiscompleteandaccurate.
SystemshouldbecapableofFTPwithSSH(alsoknownasSecureFTPorSSHFTP)ports.
Datatransfertoandfromtheapplication/webservershouldbeencryptedusingSSL3.1
128bitencryptionusingAESencryptionalgorithm.Theencryptionprocessshouldensure
pointtopointencryptionfromtheclienttotheapplication/webserver.
Each data generated out of the system such as MIS or any other information should be
timestampedanddigitallysignedsoastoensurenonrepudiation.
Page|44

Incertaincasestheremayberequirementtouploaddataintotheapplicationsystem.The
application system should provide provision to define the processes where uploading
feature has to be provided or has to be withdrawn from. Along with such provisions it
shouldalsoprovideforamechanismtodefinethetypeandsizeofattachmentsforeach
upload.
Anyuploadedfiletotheapplicationsystemshouldbescannedthoroughlybeforeallowing
theuploadedfiletoreachiFMSOdishaapplicationsystemforstorage.
8.2.6. Databases
Designaflexibledatainfrastructurethatcanaccommodaterapidchangesindatamodels
basedonchangesinbusinessrequirementsordatabasetechnologies.Caremaybetaken
toconsiderutilizationofexistingdatabaselicenseavailablewithFinanceDepartmentbutis
notmandatory.
Performbenchmarkstestsonthedatabasesbeforefinalisingthedatabasedesign.
RDBMSpackagestobeusedshouldconformtoindustrystandards.
UseOEMStandardSQLforqueryingdatabases
8.2.7. Miscellaneous
SystemsmustbedesignedwithaGraphicalUserInterface(GUI).Caremaybetakenforbi
lingualpresentation(UNICODEimplementation)thatincludesuseoflocallanguage(Oriya)
alongwithEnglish.
Provisionfordisablepeopletousethesystemisappreciable.
ThewebpagesofthisapplicationshouldsupportatleastbrowserslikeInternetExplorer,
MozilaFirefox,OperaandChrome.
DataexportfacilitytopopularformatssuchasMSOfficeandOpenOffice,PDF,XMLetc.
Systemshouldsupportemailandfaxintegration
Supportalertmechanisms(Reminders)fortimecriticalactionsandescalationmechanisms
fornonattendedactivities.
Codingstandardsmustbeadoptedtomakedebuggingandmaintenanceeasier
BusinessRulesshouldbeplatformindependent.
Functionalauthorities,notITresourcepersons,shouldberesponsibleformaintainingthe
businessrules.
FollowObjectorientedprogrammingmethodologytofacilitatesharingandmultipleuseof
standardcode.
LatestIPaddressingsystem(version6)shouldbeusedandanyolderaddressingsystemis
usedintheexistingsystemshouldbeupgraded.
Page|45

8.3. Methodology
A suggested methodology for the development and deployment is given below. The bidders are
freetoenhancetheseorsuggestalternativeswithreasons.
Prepare the detailed User Requirement Specification (ToBeProcess) document and

gettingitapprovedbythePeMT.
Preparedetailed SRSdocument as perthe ToBe Process documentand broadlevelSRS.

TheSRSdocumentshouldgivecompletearchitectureoftheproposedsystem.SRSshould
include,butnotlimitedto:
o AllDatabasestructureanddetaileddescriptionoffieldsandtables.
o Namingconventionsfollowedforthetablesandfields.
o Dataflowdiagrams(DFDs)&entityrelationship(ER)diagrams.
o Detailsofvalidationrulesandconstraints(Integrity/Check/Referentialetc.)tobe
applied.
o Formatsofallinput(dataentry)screens
o FormatofallreportsthatwouldbegeneratedbytheSystem
o Processinglogicusedforallreportsandfunctions
o Accesscontrolmechanismstoensurethatdatabasesarenottamperedormodified
byunauthorizedusers.
PresentthedetailedSRSDocumenttotheProjecteMissionTeamofiFMS.
Prepare the prioritisation plan for various module of iFMS System, in consultation with
ProjecteMissionTeam(PeMT).
Seek approval of detailed SRS document (including prioritization of software modules)

fromPeMT.
Prepare Computerisation Action Plan (Detail activities and their inter relationships,
expectedtimedurationforeachactivityandtheperson/agencyresponsible).
Install all necessary software (not defined under preinstalled software requirements)
requiredfordevelopmentandproductionenvironment.
Develop/customisetheSoftwareModulesofthesystemaspertheagreedprioritylist.
ConductthoroughtestingonthesystemfromUnitTestingtoAcceptancetesting.Testing
should be done with artificial test data followed by live test data. Testing methodology
mustincludecodereviewtoensureperformanceoptimizationofsoftwareproceduresand
functions.Finally,acceptancetestingwillbeconductedatsimulatingenvironmentofPeMT
beforedeployingontotheproductionserver.
Install and operationalize system at all locations. The deployment of the system should
onlybedoneinaphasedmannerinconsultationwithPeMT.Pilotapproachshouldbeused
forimplementationofthenewsystem.
Page|46

Provide comprehensive technical support on all aspects of running the system after the
operationalizationofthecompletesystem.
8.4. ArchitectureforiFMSOdisha
8.4.1. TechnologyPlatforms
Thefollowingtechnologyplatformsarealreadyselectedfordevelopingkeytechnicalaspectsofthe
solutionandtheserviceproviderisexpectedtoleveragethesameinanoptimalwaypossible
SolutionFeatures SelectedProduct/Framework
WebPortal OracleWebcenterSuite11g
SOA OracleSOASuite11g
ApplicationServer OracleWeblogicSuite11g
Database OracleEE11g
ProgrammingLanguage Java(JDK1.6orabove),JEE(5orabove)
ApplicationFramework Spring3.x
PersistenceFramework Hibernate,iBatis,JPA
BIServices PentahoBusinessAnalytics4.5
8.4.2. PrimaryDataCenter
IFMSOdishaITinfrastructurehasbeendesignedtoarriveatanoptimized,flexibleandanefficient
Hardware setup to meet the performance and availability requirements of the solution. This
sectiondescribestheInfrastructurelandscape.
The infrastructure at primary data center as well as disaster recovery site is designed to cater
informationinrealtime24/7model.Theobjectivesofthisarchitecturearetoprovide:
ResilienceofCoreServices
EndtoendInfrastructuremanagement
BusinessContinuitydataprotection
UseofDRinfrastructureforReporting
EfficientlyManageDataGrowth
Belowisthesummaryofproposedserverssizingarrivedatforeachofthesolutioncomponents
plannedatPrimarySite.
Sl. Description Quantity

(inNos)
1 DatabaseServer(inActiveActivecluster) 2
[2nos.IntelXeon10coreProcessor,minimum2.4GHz,Scalableto4processor,
128GBRAM,2x300GBSASHDD,2x10Gigabitconvergednetworkport,64Bit
EnterpriseLinux]
2 ApplicationServerandContentServer 4
[2nos.IntelXeon8coreProcessor,minimum2.9GHz,64GBRAM,2x300GBSAS
HDD,2x10Gigabitconvergednetworkport,64BitEnterpriseLinux]
3 ServerPoolforReport 1
Page|47

(inNos)
HDD,2x10Gigabitconvergednetworkport,64BitEnterpriseLinuxand
Virtualizationsoftware]
4 WebServerforInternetDMZ&IntranetDMZ 4
5 ServerPoolforvariousutilityservices 2
VirtualizationSoftware]
6 ServerPoolforDirectory,IDM,AccessManager 3
7 BackupManagementServer 1
8 EnterprisemanagementServers 7
HDD,2x10Gigabitconvergednetworkport,64BitWindows/EnterpriseLinux]
9 QA&TrainingSetupServerpool 3
10 SANStoragewithredundantstoragecontroller 1
[6TBusablespaceinRAID10with300GBSASHDD,scalableto12TB,8000disk
IOPS]
11 TapeLibraryfordatabackup 1
[2nosLTO5FCTapeDrivewithminimum40cartridgeslots]
12 ConvergedNetworkSwitchwithminimum48x10Gigabitconvergedport,8x 2
8Gb/sFCPorts
8.4.3. DisasterRecoverySite
Disaster Recovery Site has been proposed with 50% server capacity of primary site production
environment.DatawillbereplicatedbetweenPrimaryandDRsiteusingOracleDataguard.Data
Guard is the data protection and availability solution for Oracle Database. It provides the
management, monitoring, and automation software to create and maintain one or more
synchronizedstandbydatabasesthatprotectdatafromfailures,disasters,errors,andcorruptions.
NonOracle Dataincluding any filestorage, Portal data etcwill bereplicatedtothe DR site using
StoragebasedreplicationofZFSStorageArray.TotalnumberofdifferenttypeofserversonDRsite
isasgivenbelowandthespecificationisasgivenintheprevioussectionfortherespectiveservers.
Page|48

(inNos)
1 OLTPDatabaseServer 1
2 ApplicationServer 2
3 ReportServer 1
4 WebServersforInternetDMZ&IntranetDMZ 2
5 Serverforvariousutilityservices 1
6 ServerforDirectory,IDM,AccessManager 1
7 BackupManagementServer 1
8 EnterpriseManagementServer 7
9 SANStorageArray 1
10 TapeLibrary 1
8.5. ReportingRequirements
Following reporting / documentation would need to be maintained by the service provider in
additiontothestandardreportingrequirements.
Project Implementation Plan: laying down all the project activities, the expected
durations and the dependency relationships between these activities and who is
responsibleforeachactivity.PIPalsolaysdownalltargetmilestonedates.
Communications Plan: Listing all stakeholders in the project, defines their roles, and
providescontactinformation.
QualityAssurancePlan:Documentingtheplannedandsystematicpatternofallactions
necessary to assure confidence that the software developed will conform to the PRDs
functionalandtechnicalrequirements.
Interface Control Document: Documenting the interface characteristics of one or more
systemsanddocumentsagreementsbetweeninterfaceowners.Itcontainsinformation
on both the physical and data element requirements that are necessary to make the
transferofinformationbetweensystemsfeasible.
Test Plan: Containing information on the software test environment to be used for
independent testing, the test cases to be performed, and the overall testing schedule.
This includes methodology, schedule, resources, tools, procedures, environment
definition,testcases,andsoftwaretestresults.
OperationsManual:Providinginstructionsforinstallingtheapplication,troubleshooting,
interpretingmessagelogs,andFAQs.
User Manual: (both online and paper copies) providing detailed instructions on how to
usethesoftware.Inaddition,itdescribeshowtoaccess,submitinputsto,andinterpret
outputsfromtheapplication.
Periodic Status Report: communicating the status of activities completed activities in
progress,outstandingissuesandrisks,andanyimpactorpotentialimpacttotheproject
schedule. Service provider is required to submit progress reports as per the agreed
format.
Request(s)forChange:documentinganyalterationsrequired.
Page|49

User Feedback Forms: documenting things that went well and those that didnt and
opportunitiesforimprovement.Alsodocumentinglodgedcomplaintsbytheuser,action
plan,actiontakenandpendingorresolutionstatusofcomplain.
ExitPlan:documentingsystematicproceduretotransferknowledgeformaintainingthe
systeminfuturedays.
8.6. FunctionalComponents
In integrated Finance Management System, Odisha, following functional modules are to be
developed, integrated with existing iOTMS system as well as external system such as CPSMS,
WAMIS, HRMSOdisha, VLC systems etc and implemented at targeted user offices in 3 different
phases. It is important to mention that new accounting codes practice recommended by
Sundarmurthi Committee should be followed throughout iFMSOdisha. Existing iOTMS should be
revisedaspernewaccountingcodes.
Functionaldescriptionsofabovemodulesaredescribedbelowindetail.
8.6.1. BudgetPlanning&Preparation
Using Budget Planning and Preparation module Drawing Disbursing Officer (DDO), Estimating
Officer (EO), Controlling Officer (CO), Administration Department (AD), and Finance Department
(FD) can submit, consolidate and approve budget estimate online at different levels. Application
willfacilitatethehighermanagementoftheGovernmenttodrilldowntheentirebudgetuptoDDO
level.Ultimatelysystemwillgenerateandprintthefinalbudgetandotherbudgetrelatedreports
inprescribedformat.
Inthismodule,ControllingOfficeronwardstheprocesshasbeenfairlystabilizediniOTMSIandis
necessaryforbackwardintegrationfromControllingOfficertillDDO.
8.6.1.1. ProcessDefinition:NonPlanBudget
Sl. STEP ACTOR

1 For Budget preparation, DDOs to submit estimates, online, using
prescribed formats, to the Estimating Officers (EO). Actual
DDO
expenditure and receipt of current as well as last 3 years will be
availablefromexistingiOTMSTreasurymodule.
2 Estimating Officers to prepare their Budgeting Requirements, will
collectDDOwiseestimatesonlineinaprescribedformatdefinedby
EstimatingOfficers
FinanceDepartmentandcompilethereceivedestimates.Generate
COwiseestimatefileandforwardsittoconcernedCOs.
3 Reviewingtheestimate,forwardedbyEO.Capabilitytoconsolidate
the estimates, forwarded by EO, adds some new items / modifies
existingiteminconsolidatedestimate.UltimatelyCOcangenerate ControllingOfficers
CO wise estimate file and forward it to concerned Administrative
Department(AD).
4 Reviewingandconsolidatetheestimates,forwardedbytheCOsof
AD
the department, AD can add some new items / modifies some
Page|50

Sl. STEP ACTOR
existing items in consolidated Departmental estimate. Ultimately
AD generate Departmental Budgeting requirements file and
forwardittoFinanceDepartment(FD)forprebudgetscrutiny.
5 ProvisionforFinanceDepartmenttoscrutiny(prebudgetscrutiny)
the departmental budget estimate and finalize it for each
department individually. During this time Finance Department can FD
addsomenewitems/modifiessomeexistingitemsindepartmental
estimate.
6 ProvisionforFinanceDepartmenttocompiletheentirebudgetand
generate demand for grants for Plan & NonPlan for all FD
departmentsandReceiptbudget.
7 Capability to Print Entire Budgetary Book and other statutory

FD
reportsinprescribedformat.
8.6.1.2. ProcessDefinition:PlanBudget
Sl. STEP ACTOR

1 ProvisionforeachADtoprepareAnnualPlanProposalonlineand
AD
sendittothePlanning&CoordinationDepartment
2 Provision for Finance Department to prepare the Forecasts of
FD
ResourceassessmentfortheAnnualPlanonline.
3 Provision for P&C Department to receive Forecasts of Resource
P&CD
fromFinanceDepartment(FD).
4 P&CDepartmenttoacceptAnnualPlanProposalfromallADs.
P&C Department consolidate Annual Plan Proposal, received P&CD
fromallDepartments.
5 A.G will provide the actual expenditure data of the past years.
AG,FD
Expendituredatacanbeverified/downloadedfromiOTMSsystem.
6 P&C Department accept the actual expenditure data of the past

years,preparedbyA.G.
P&CD
P&CDepartmenttocomparetheexpendituresestimatesprojected
fortheAnnualPlanyearwithactualofthepastyear.
7 P&C Department to finalize consolidated Annual Plan Proposal
P&CD
andResourceForecastandsendthesetoPlanningCommission.
8 P&C Department to receive Sector/SubSector and Scheme wise
plannedoutlayfromplanningcommission.
P&CD
P&C Department to splits Sector/SubSector and Scheme wise
planned outlay, received from planning commission among the
Page|51

Sl. STEP ACTOR
departments.
P&C Department to transfer the Sectoral Outlays for each
DepartmenttotheconcernedAD.
9 ADtoreceiveSectoralOutlaysfromP&CDepartment.
ProvisionforAdministrativeDepartmentstoprepareNewDemand
SchedulesfortheplanschemesonlineonthebasisofSector/Sub AD
Sector and Scheme wise plan outlay for the Department. Follow
StepNo7.
8.6.1.3. Functionality:BudgetPlanning&Preparation
Sl. Functionality
1 Systemshallbeworkflowbased.Noonecanupdateanybudgetestimate,whenupper
leveluserinthehierarchyhasacceptedtheestimate.
2 Systemwillfacilitatetheupperlevelusers(EO,CO,AD,FD)todrilldowntherespective
sectionoftheentirebudget.
3 SystemshallhavethecapabilitytoDeployandImplementDynamically,Assumptions/
BusinessRules,GoverningBudgetPreparation.
4 SystemshallcapabilitytoAnalyzeTrendsfrompreviousBudgetsandtheUtilization
PatternsforprovidingaDecisionSupportSystemwhichshouldbeCapableofForecasting.
5 SystemshallabletoprojecttheexistingLiabilitiestoEstimatingOfficers.
6 SystemshouldfacilitateusertoprepareAnnualBudgetaswellasVotesonAccount
BudgetandSupplementaryBudget.
7 Provisionforbudgetestimatingofficerstopreparetheirbudgetingrequirements,DDO
wise,onlineusinginterfaceprovidedbytheproposedsysteminaformatprescribedby
financedepartment.
8 CapabilitytocompilebudgetestimatingofficersbudgetingdataCOwise.
9 Capabilitytocapturestaticdatafromwithdatarepositorieslikeworksheets.
10 CapabilitytoprintentirebudgetaryprovisionsofbothStatesector(B.E,AFS,Provisionof
Planschemes,DetailedestimatesofRevenueandotherestimatesetc.
8.6.2. DebtManagement
TheProposedSystemwillmaintainvarioustypesofloanswhicharetakenordisbursedbyGovt.of
Odishaindetailasitisavailableinloandocumentsalongwiththetransaction.Apartfromthisthe
proposed system will also be capable to capture details of market borrowings, guarantee (govt
securities),andgovernmentinvestments.
Inadditiontoaccountinginformation,theproposedsystemwillalsoprovideimportantinformation
requiredintheformulationoffiscalpolicysuchasforecastsofdebtservicingliabilities.
8.6.2.1. ProcessDefinition:GuaranteeIssue&Monitoring
Guaranteeissue&monitoringcompromisesofguaranteestoPSUsincludingguaranteeproposal,
guaranteedeed,recoveryofcommissionetc.
Page|52

Sl. STEP ACTOR
1 Guarantee detail capture against loan amount requested from

PSUsforwhichgovtstandsasguarantor.Assetandliabilitydetails,
FD
status of organisation also principal & interest repayment,
guaranteefeesdetailsentry.
2 FinanceDepartment(FD)approvesrequestedloanamount. FD
3 Actual Loan Taken and schedule of repayment generated against

FD
theuniqueguaranteeid.
4 Repayment (principal & interest) capture of actual loan taken will

FD
bedoneaccordingtotherepaymentschedule.
5 Entry of expenditure details of borrowing institute against
FD
guaranteeid.
6 Theguaranteecommission(fees)entryonoutstanding. FD
8.6.2.2. ProcessDefinition:LoanfromFinancialInstitute
LoanstakenfromNABARD/LIC/GIC/ExternallyAidedSchemes(GovtofOdishaBorrower):
Sl. STEP ACTOR

1 Creation of loan profile providing loan id and capture loan details
from financial institutes (NABARD ,LIC, GIC etc.), externally aided
FD
schemes.Thisincludesinstalmentwisereleaseofloanamountand
repaymentdetailscapturewhichgeneratesrepaymentSchedule.
2 Generate demand statements/communications for individual loan

FD
accounts.
8.6.2.3. ProcessDefinition:LoanfromGoI
LoansfromGovtofIndia(GovtofOdishaasBorrower):
Sl. STEP ACTOR
1 Based on sanction order, creation of loan profile providing loan id

AG
andcapturetheloandetailsandtermsandconditionsofloan.

FD
accounts.
8.6.2.4. ProcessDefinition:LoansbyGoO
LoansandadvancesgivenbyGovtofOdisha:
Sl. STEP ACTOR

1 Captureexpendituredetailsagainstloans&advancesofthestate FD
Page|53

govt.
2 Outstanding Loans/ advance from Govt. of Odisha and its

FD
repaymentbycorporations/governmentundertakingsetc

FD
accounts.
8.6.2.5. ProcessDefinition:Marketborrowingloans
Sl. STEP ACTOR

1 Loanfrommarketarecapturedandrepaymentdetailsofprincipal
andinterestarealsocaptured. FD
Basedonrepaymentdetailsrepaymentscheduleisgenerated.
2 Repaymentcapturedonschedulewise. FD
8.6.2.6. Functionality:DebtManagement
Sl. Functionality
1 SystemshallautocalculateguaranteefeesbasedonPSUs(forseveralLending
Institute).Anyfractionperiodforsanctionofguaranteeandliquidationofloanshallbe
treatedasoneyearforcalculationofguaranteefees.
2 Systemshallgenerateautorepaymentscheduleforactualguaranteedloantaken.
3 System shall generate auto repayment schedule for loan taken or given including
marketborrowing.
4 Thesystemshallintegratebudgetdistribution,budgetpreparation&treasurymodule.
8.6.3. FundManagement
Fund management in the Government is an important process. The channels for revenue
collectionsandexpendituresaremultiple.TheProposedFundManagementsystemwillprovideto
collect the receipts and payments data from different Channels, daily, aggregate it and give a
ComprehensivePicturetotheFinanceDepartment.
8.6.3.1. ProcessDefinition:FundManagement
Sl. STEP ACTOR

1 AllthereceiptsandexpenditureoftheStateshouldbeconsolidated
and statements available to generate reports for comparison, FD
summingupetc.,
2 AG,Odishawillgivetheadjustmentdataonthegrantsandloansfor
complete informationon outgoingandincomingfundstotheState AG(O)
Government.
3 Capability to receive data from RBI, regarding intrastate aggregate
RBI/FD
receipts and expenditure during the day and reconcile with data
Page|54

Sl. STEP ACTOR
fromthetreasury.
4 Provision for electronic receipt of DMS, and confirmation through Treasury/Link
VDMSforeachtreasuryandLinkBank. Bank
8.6.3.2. Functionality:FundManagement
Sl. Functionality
1 Thesystemshouldensurethatithasdatainrealtimefromalltheinterfacingmodules
2 Thesystemshouldbecapabletoforecastquantumofreceiptsbasedonpastpattern,
andexpenditurebasedonplannedflowforagivenperiod.
3 Thesystemshouldbecapabletoreceivedailyscrollselectronicallyfromagencybank
branchesand/orRBI
4 The system should be capable to reconcile with treasury records, confirm the
transactionsandreportdiscrepancies
5 Thesystemshouldbecapabletoprovidecorrectionsafteraccountsforamonthhave
beenclosed
6 Systemshouldbecapabletogeneratedifferentreportsbasedonforecast.
8.6.4. MonitoringofWaysandMeans&RBIIntegration
Ways and Means Management refers to the mechanism that enables the State government to
managetheshorttermliquidityproblems.Inordertotideovertheshorttermliquiditycrunch,the
RBIprovidestheStates,waysandmeansadvances(WMA).AsastandardpracticeeachStateneeds
tomaintainacertaindailyminimumbalancewiththeRBI.
Ways & Means Management also comprises of management of State Government Account
maintainedwithRBIwithaviewtoensurethatallthefinancialreceiptsandpaymentshavebeen
duly accounted and reconciled. The transactions initiated at treasury, agency bank, department
level,AG,RBIetc.shallberequiredtobereconciledtoensurethatallthereceiptsandpayments
havebeendulyaccountedinStateGovernmentAccount.
TheoverallWaysandMeansprocesseshasbeenclassifiedunderthefollowingprocesses
Reconciliation
Monitoring
8.6.4.1. ProcessDefinition:Reconciliation
Thereconciliationprocessshallcoverofallreceiptandpaymenttransactionsatthetreasurylevel,
AGlevel,RBIlevelimpactingtheStateGovernmentAccount.
Sl. STEP ACTOR
Page|55

1 For all the receipts and payments made by the Link Bank, escroll
LinkBank/
shall be prepared for receipt and payments. The escrolls shall be
Authorized
digitallysignedforuploadinginiOTMSportal.
Bank
The escrolls shall also be sent to the link bank branch of Agency

bank.
2 Treasury shall unencrypt escrolls. The iOTMS will identify any

exceptionaldifferencesbetweentransactionscapturediniOTMSand
DTO/STO
escrollreceivedfromauthorizedbanks.

In case there is any difference, the same shall be reported to the
bankforcorrection/rectification/reconciliation.
3 LinkBank/
LinkbanksendseScrolltoRBIfordebit/creditofStateGovernment
Authorized
Account.
Bank
4 Based on the escroll, the RBI shall debit/ credit the State
GovernmentAccount.
RBI shall also debit/ credit the Account with the advice received
from AG for payments made to Central government, interstate
transaction settlement, etc. and also advice received from other
RBI
stateAG/RBIbranchoffices/GoI.
Subsequent to accounting in State Government Account, RBI shall
preparedigitallysignedClearanceMemoforintimationtoFD/AGof
GoO. The Clearance Memo shall be mapped with the transaction
leveldetails.
5 Link Bank shall prepare electronic Day wise Monthly Statement (e

DMS)atmonthendanduploaditiniOTMSportal.
Treasury shall unencrypt and update the eDMS, to generate the
exception report, if any. In case there is any difference, the same Link Bank/
shall be reported to the bank for correction/ rectification/ DTO/STO
reconciliation.
AftertheeDMSisverified,theeVDMSispreparedanduploadedin
iOTMSandsenttoLinkBankandAG.
8.6.4.2. Functionality:Reconciliation
Sl. Functionality
1 System shall be integrated with Link Banks system to facilitate transfer of digitally
signedonlinereceiptofDailyonlinescrollandeDMS.
2 Systemshallfacilitaterectificationofentryforreconciliationdifferencesidentified.
3 Systemshallraiseexceptionreportingforthetransactionsnotreflectedinescrollsbut
reflectediniOTMSand/ortransactionsreflectedwithdifferentamountsinescrolls
andiOTMS.
Page|56

Sl. Functionality
4 Systemshallcaptureonpriority,thetransactionsnotreflectedinthepreviousdayse
scrollforthecurrentdaysreconciliationprocessthroughaplusminusmemosystem
5 SystemshallbeintegratedwithRBIssystemtofacilitatedigitallysignedonlinereceipt
ofClearanceMemoandReserveBankDepositStatement
6 SystemshallautoreconcileDailyonlinescroll,onlineDMS,onlineClearanceMemo
7 SystemshallfacilitatesubmissionofdigitallysignedexceptionreporttoLinkBankand
RBI.
8 ForSettlementwithOtherStatesAG,Systemshallfacilitateautoreconciliationofthe
DatapertainingtoOtherStateAGtransactionsasisavailableiniOTMS
database
Inward/OutwardClaimssubmittedbyOtherStateAG
RBIadvicerelatingtodebit/creditoftheStateGovernmentAccount
pertainingtointergovernmentadjustment
Systemshallgenerateexceptionreportonthereconciledamount
8.6.4.3. ProcessDefinition:Monitoring
The monitoring process comprises monitoring of ways and means position of the State
Government by FD. FD shall have the information regarding daily receipts and payments, RBD
balance,projectedreceipts,trendsofexpendituretobeincurred,etc.throughadashboardview,
to facilitate decision making on borrowings if any to be undertaken, stoppage of any particular
budgetheadtoprioritizeessentialpaymentse.g.salary,pension,etc.
Sl. STEP ACTOR
1 FD shall have availability of the financial information from its own

sourcei.e.iOTMS.
Also,iOTMSshallincorporate
eScrolls/eDMSsubmittedbytheLinkBank
eClearanceMemo,eRBDsubmittedbyRBI
FD shall have dashboard view of entire receipt & payment figures of Finance
GoO. This shall facilitate decision making on borrowings if any to be Department
undertaken, stoppage of any particular budget head to prioritize
essentialpaymentse.g.salary,pension,etc.
TheFDhastomonitortheabovepositiontoensurethatitdoeshave
totakeanyoverdraft/advance/stoppageofpaymentsandmakefund
arrangementsaccordingly.

Page|57

8.6.4.4. Functionality:Monitoring
Sl. Functionality
1 Capability to project the ways & means position over a period of time using What if
scenarios/sensitivityanalysis
2 Real time monitoring and controlling the W&M position of the GoO including advances
(Special/Normal/Overdraft)taken,ifanythroughW&Mdashboardandby
Availabilityofprovisiontostopand/orreleaseaspecificorallpaymentsbasedon
W&MpositionoftheGoO.
Settingupoftheallowablepaymentlimitsfortheperiodday/week/month.
Enablingpaymentbeyondallowablelimitsonlyuponauthorizationbythe
concernedauthority.
Scheduling&prioritizingvariouspayments.
3 ThefunctionalitiesrelatedwithW&Mmanagementwouldbeaccessedbyrestrictedusers
asperthedirectivesoftheFD.
4 Shallprovideonlinealertsandexceptionreporting.
5 Systemshallfacilitateinundertakingfinancialanalysisincludingratio,etc.
8.6.5. SchemewiseExpenditureTrackingIncurredOutside/InsideConsolidatedFund
Certain transactions are performed by the Government or its agencies outside the ambit of the
Treasury,whichpertainstothefundsreceiveddirectlyfromGOIforcertainschemes.
TherearetwowaysthroughwhichGOItransfersfundstovariousschemes,namely,
BydirectcredittothebankaccountsoftheImplementationagency
ByroutingthemthroughtheStatesConsolidatedFund.
Thismoduleismeanttotracksuchtypeofgrants,aswellasexpendituredoneagainstthem,within
the iFMSOdisha and generate consolidated accounts & reports. This module is also expected to
integratewiththefollowingagenciesforsharingvariousfinancialdetailsaboutsuchschemeswith
them
CPSMS(CentralPlanSchemeMonitoringSystem)ItwillinformiFMSOdishaaboutthe
releaseoffundsbyGOI.WhileonasimilarscaletheiFMSOdishawillprovidebackfinancial
details about all transactions performed over total scheme funds including the states
contribution.
RBI
Banks

8.6.5.1. ProcessDefinition:SchemewiseExpenditureTracking
Sl. STEP ACTOR
Page|58

Sl. STEP ACTOR
1 Details such as beneficiary scheme, amount, the mode of transfer,

CPSMS
etcwillbesharedbyCPSMS.
2 RBI is responsible for crediting to the consolidated funds of the

state;thebanksareresponsibleforcreditingtotheconcernedbank
accounts(incasetheschemeisbeingadministeredusingaseparate RBIandBank
bank account). Integration with Bank and RBI will provide this
informationtoiFMSOdisha
3 Total scheme funds may have both GOI share as well as states
share. Implementing
Implementing Agency (IA) will withdraw the fund documenting the Agency(IA)
sharewhichhasbeenwithdrawn.
4 Implementing Agency, AG(O), FD will enter all types of transaction
against a scheme. All the transaction will be entered scheme wise, AG(O),FD,IA
treatingtheschemeasalogicalunit.
5 IntegrationwithIAsystemwhereverpossibleisrequiredinorderto
IAsystem
getthetransactiondetailsagainstaparticularscheme,withoutany
Integration
humanintervention
6 Reconciliation will be done against the various transaction entered

System
intothesystem,bydifferentagencieslikeAG,CPSMSintegration,IA,
generated
FD.
8.6.5.2. Functionality:SchemewiseExpenditureTracking
Sl. Functionality
1 System should have capability to integrate with CPSMS to capture release of GOI
grantsforvariousschemes.
2 System should have capability to integrate with RBI and Banks for downloading the
confirmationofcreditingoffundstothebeneficiaryscheme.
3 System should have capability to Implementation Agency to withdraw total scheme
fundsfromtheconsolidatedfundsofthestate.
4 System should have capability to agencies like AG, Implementation Agencies and
FinanceDepartmenttocapturetransactionsagainstvariousschemes.
5 SystemshouldbecapabletoprovideamechanismtotheFinanceDepartmentfor
definingtherulesandregulationgoverningeachscheme.
6 SystemshouldbecapabletoregulateDDOstreasurytransactionsincaseofdefaultin
respectofschemereportingandaccountupdation.
7 SystemshouldbecapabletocommunicatetotheCPSMSthedetailedMISonfinancial
transactionsperformedundereachscheme.
Page|59

8.6.6. MonitoringandControllingUtilizationCertificate(UC)
UtilizationcertificatesarerequiredtomonitorprogressonschemesfundedbyGovernment.
Variousdepartmentsusevariousformatsforutilizationcertificate.
8.6.6.1. ProcessDefinition:ControllingUC
Sl. STEP ACTOR

1 DDO will enter the actual scheme wise expenditure details in the
system against the treasury voucher number after treasury passed DDO
thebill.
2 CO will consolidate the expenditure; scheme wise/chart of account

CO
wiseand
3 Department will further consolidate the CO wise expenditure and
willpreparetheutilizationcertificatedepartmentwiseandchartof
Department
accountwiseandschemewise.Utilizationcertificatewillbeproduce
forGrantInAidbilltypeonly.
4 AG/FDwillseetheUtilizationcertificatethroughthesystem AG/FD
8.6.6.2. Functionality:ControllingUC
Sl. Functionality
1 System should be capable to provide a validation rule on release of further amount
basedonthesubmissionofUC.
2 SystemshouldbecapabletogeneratereportslikesubmittedUC,UCpendingetc
3 System should be able to consolidate the expenditure details scheme wise/ chart of
accountwiseautomaticallyatCOandDepartmentlevel.
8.6.7. PensionFinalization,preparationofPensionPaymentOrder(PPO)
UsingthesemoduleuserslikePensionSanctioningAuthority(PSA),PensionIssuingAuthority(PIA),
ControllerofAccounts(PIA),TreasuryOfficercanprocessandapprovethePensionPaymentOrder
at different levels. Application will facilitate the Pension Department to prepare the Pensioners
bookaccordingtoemployeesavailabledata.UltimatelysystemwillgeneratethePPO/GPO/CPO
fromthesysteminprescribedformat.
8.6.7.1. ProcessDefinition:PensionManagement
Sl. STEP ACTOR

1 HeadoftheOfficeprepareslistofemployeeswhoareduetoretire HeadofOffice/
within24to30months.InformationtobecollectedthroughHRMS. Designated
Officer
Page|60

Sl. STEP ACTOR
2 Therecovery/outstandingpositionoftheadvancesandlicensefees
(foroccupationofgovernmentquarters)areascertainedfromthe
HeadofOffice/
DDOoftheestablishment,forwhichNDC(nodemandcertificate)is
Designated
tobeobtainedinrespectofadvance(s)takenbytheemployeeand
Officer
alsoforlicensefee,ifhe/sheisinoccupationofgovernment
quarters.
3 Thelist,preparedinstep1,iscommunicatedtoPIAonlinetoobtain HeadofOffice/
No Demand Certificate of the employees. A copy is send to the Designated
concernedemployee. Officer
4 Before6monthsofretirement,employeewillfillupandsubmitsall
the pension related forms online/ offline to apply for sanction of Employee
pension/retirementbenefits.
5 Thepensionpapersarethenscrutinizedbytheofficewithreference HeadofOffice/
totheentriesmadeintheservicebookoftheemployee.Service Designated
bookinformationwillbefetchedfromHRMS. Officer
6 Thepensionpaperssubmittedbytheemployeearetobe HeadofOffice/
countersignedbythedesignatedofficeroftheestablishment/office Designated
oftheemployeeinwhichhelastserves/served. Officer
7 The countersigned papers are then submitted to the PSA (Pension HeadofOffice/
sanctioningauthority)forsanctionofpension/retirementbenefitsin Designated
favouroftheemployee. Officer
8 The PSA may sanction provisional pension, gratuity and commuted
amount of pension in favour of the employee subject to his
satisfaction and that too within his jurisdiction with copy of the
sanctionorderstothePIA.Whilesanctioningtheprovisionalamount
ofretirement benefits, duediligencearetobe madebythe PSAin PSA
regard to the admissible rate of different retirement benefits
applicable to the incumbent as per the prevailing rules and to see
thattheamounttobesanctioned/releasediswithinthepermissible
limit.
9 PSAshallhavetofurnish(withhissignature)thepensionpapersof
theemployeestothePIAforfinalsanctionofpension/retirement PSA
benefits.
10 PIA examines the information as per the provision of the pension

rule, and if any discrepancy is found, sends it back to the PSA. PIA
PIA
calculatestheemployeespension,gratuityandcommutedvalueof
pensiononthebasispensioncalculationrulesandregulation.
11 Systemwillgenerate:
PIA
A printed authorization letter along with PPO, CPO and GPO
Page|61

Sl. STEP ACTOR
numberfortreasuries.
A dispatch letter with the dispatch number of the
PPO/CPO/GPO/PensionCalculationSheet.
Dispatch letter, Authentication letter and the relevant documents
canthenbesenttotheconcernedtreasury.
Incaseofotherstatepensioni.e.pensiontobedisbursedinother
state, PIA sends this Dispatch letter, Authentication letter and the
relevantdocumentstoAG.
12 PIAmonitorsthepensionpreparationcasesthroughvariousMISlike
Monthly Report on Department wise Finalized Pension Case and
Revisedcase,ReportonDepartmentwisePendingCases,Report PIA
on Pension Cases Returned with Objection, Monthly Progress
ReportRegardingMonitoringPensionCasesetc.
13 PIA will electronically transmits/uploads the same to treasury
PensionIssuing
system, required for generation of various pension bills at treasury
Authority(PIA)
level.
14 Treasury Officer will validate the uploaded pensioner details after Treasury
thesubmissionofPPObookattreasurybythepensioner. Officer
8.6.7.2. Functionality:PensionManagement
Sl. Functionality
1 IntegrationwithHRMSisrequiredsothatpensionrelatedinformationlikeName,
Address,Qualifyingservice,Lastbasicamountetcwillbeautopopulatedatthetimeof
pensionformfillupbytheemployee.Thisintegrationisalsorequiredtogetthelistof
employeeswhoareduetoretirewithin24to30months.Servicebookinformationcan
alsobefetchedfromHRMS.
2 Theremustbeboththefollowingtwooptiontopreparethelistofemployeeswhoare
duetoretirewithin24to30months.
Manual:Userwillentertheinformationoftheemployeeonebyoneandthe
thenpreparesthelistthroughsystem.
HRMS:UsingthebenefitofintegrationwithHRMS,Usercangetthelist
withoutmanuallyenteringtheretiringemployeesinformation.
3 Theremustbeafacilityfortheemployeetofilldifferenttypesofpensionformsoff
lineanduploadthesametoHeadoftheOfficeonlinelatter.
4 IntegrationwithPIAisrequiredsothatHeadoftheOfficecansendonlinerequestto
PIAfortheNDC(NoDemandCertificate)oftheretiringemployee.
5 TheremustbeaprovisionforHeadofOfficetomodifysomedata,filledbyemployee,
inaccordancewithservicebookoftheemployee.Inthatcase,whenpensionfileis
Page|62

Sl. Functionality
forwardedtoPSA,PSAmustbeabletoviewtheoriginaldataalongwiththemodified
dataandremarksifany.
6 Digitalsigningfacilityisrequiredatdifferentstagesofthepensionfinalizationprocess.
7 Systemwillprepare"PensionAssessmentCumDataSheet"toprintthePPO,CPO,
GPOBookbasedonthepensionset.
ProcessingofpensionsetwouldleadtogenerationofauniquePPOnumberforeach
approvedpensioneranddispatchofPPObookusingaworkflow.
NoonecanupdateanyInformationofPensioner,ifupperleveluserinthehierarchy
hascompletedtheirapproval.
8 SystemwillfacilitatetheuserstouploadvariousscannedcopyofthePensioner.
9 Systemshallhavethecapabilitytoconvertthepensiontypefromregularpensionto
familypensionincaseofdeathofapensioner,basedontherequestandrecords
receivedfromthespouseofthepensioner.
10 Followingdocumentswillbeprintedfromsystem.
.PPO
.CPO
.GPO
11 ThestatusofPPOBookprocessingatdifferentstagescanbemonitoredusingPortal.
12 EmailandSMSnotificationfacilitymustbepresentinthesystem.
8.6.8. TeachersProvidentFund(TPF)
TheproposedsystemwillbecapabletoincorporatethefunctionalitiesofTeachersProvidentFund
(TPF)asitismaintainedbythestateControllerofAccounts(CoA).Thepurposeofthismoduleisto
store the monthly subscription of the amount towards TPF of teachers of government aided
educationalinstitution,andfinallycalculatesthefinalpaymentamountatthetimeofretirement.
8.6.8.1. ProcessDefinition:TPF
Sl. STEP ACTOR

1 DDO will submit the monthly salary bill at treasury along with the
TPF schedule. TPF schedule will contain amount towards TPF with DDO
theTPFaccountnumberoftheconcernedperson.
2 The system will use this schedule and will post the monthly
Treasury
subscriptionalongwiththeTPFnumber.
3 A consolidated DDO wise TPF amount will be available from the
Controllerof
treasury. TPF module will validate the schedule with the
Accounts(CoA)
consolidatedfigure.
4 TheTPFschedulewillbeimportedautomaticallyinthesystem.This CoA
Page|63

Sl. STEP ACTOR
isknownasCreditposting
5 CoA will enter the debit sanction letter, issued by the concerned
DDO, against the loan taken by the employee. The loan amount
taken will deducted from the subscription amount. At the time of
deduction of amount thesystem willtakecare ofthe fact whether CoA
debitsanction letterhas beenenteredornot.If it isunavailablein
thesystemthensystemwillnotethatandamessagewillbesentto
theconcernedDDO.
6 For temporary advance the concerned person will repay the loan
amountmonthlyastheamountfixedbyhisoffice.
A debit schedule available for this will be entered into the system,
towardstherecoveryoftheloan.
CoA
Thisschedule will bevalidatedwith the consolidateddebit amount
of the bill available in treasury system, and according full or part
wantwillbegenerated.Thisisknownasdebitposting.

7 A yearly interest calculation will be done by the system for both

debit and credit posting and subscriber wise account slip will be
generated.
CoA
Aftercalculatingtheinteresttheaccountforthatyearwillbeclosed
andTPFaccountnumberwiseopeningbalancewillbecarryforward
tothenextyear.
8 Finallyatthetimeofretirementthefinalamounttobepaidtothe
CoA
concernedemployeewillbecalculatedbythesystem.
8.6.8.2. Functionality:TPF
Sl. Functionality
1 SystemshouldbecapabletoimporttheTPFschedulebytheDDOautomaticallyina
batchmode.
2 The TPF schedule imported by treasury should be available to CoA without any
furtherintervention.
3 SystemshouldhavecapabilitytogenerateeMailtoDDOincaseofanydiscrepancy
foundlike,subscriptionamountnotavailable,debitsanctionletternotavailablebut
debitscheduleavailableetc.
4 Systemshouldbecapableenoughtocalculatetheyearlyinterest,basedonthedata
available,andbasedontheparameterslikeinterestrateetc.
5 Systemshouldgeneratesubscriberwiseaccountslipattheendoftheyear,inapre
Page|64

printedformatandinaserieswisebatchmode.
6 Systemshouldhandletheworkflowatthetimeoffinalpaymentonsuperannuation.
8.6.9. DocumentManagement
The purpose of the Electronic Document Management System (EDMS) is to make use of
technologiesinDocumentScanning/Imaging/uploadingforthepurposeofmakingthedocuments
availableinelectronicformattofacilitatethebusinessprocessanddecisionsupportsystems.
TheEDMSshallbebasedonopenstandardsandshouldenablemanagementofcriticalinformation
stored in an electronic format through information capture, document imaging, and Electronic
Document Management. Information capture includes receiving, processing, and managing
electronic information in native file formats. Document imaging includes scanning, indexing,
storingviewing,andannotations.
Electronic Document Management includes checkin/checkout, version control, and document
handling. This system would facilitate online submission and processing of Treasury bill, budget
Demands for grant annexure, files etc. This would mean execution of a workflow connecting
authoritieswithintheTreasurydepartment,includinguserswithintheheadoffice.
8.6.9.1. ProcessDescription:DocumentManagement
Sl. STEP ACTOR

1 Existing documents/files are scanned and uploaded into the
Operator
documentmanagementsystemalongwithuniquefileid.
2 Fileoranydocument/letterissubmittedasperhierarchydefined
Approver
forprocessingandapproval.
3 Userlogintothesystemtoreviewthedocument,addannotation, Operator/
createsupplementaryonlinedocument. Approver
4 Userafteraddingappropriatenotingtothefile,forwardittothe Operator/
higherlevelinhierarchy. Approver
5 Eachfilewilldigitallysignedbytheuserforapproval Operator/
Approver
6 Reportonfilestatusaregeneratedoutofthesystem Operator/
Approver
8.6.9.2. Functionality:DocumentManagement
Sl. Functionality
1 Systemshall have auser friendly interfaceandshallpresentahomepagewhichgives
the user access to files, applications, knowledge bank (Government orders, circulars,
notificationsetc.),alerts,noticeboardanddashboard.
2 TheDMSsolutionshouldsupportallmajorwebbrowsers(InternetExplorer,Netscape,
MozillaFirefox,Operaetc.)andvariousOperatingsystemslikeWindows,Linux,etc.for
Page|65

serverconfiguration.
3 UsersshallbeabletoaccessthesystemDMSsystemona24x7basis.
4 The system shall have Multilevel secure access to the system and Access permission
shallbegrantedonlytothosewhosebonafideshavebeenestablished.
5 Thesystemshouldprovidecapabilitytocreateformsforvarioustypesofapplications
relatedtotheworkingofTreasuries.
6 The system shall provide comprehensive search capability to search in file index and
contentswithinafile.
7 ThesystemshouldhaveinbuiltBackupprocedureandrelatedreminders.
8 Theusershallbeabletoaccordbulkandroutineapprovalswithoutopeningafile.
9 ThesystemshallleaveanextensiveAuditTrailatalllevels.
8.6.10. Works&ForestBillprocessingandAccountsgeneration
Junior Engineer (J.E) prepares the bills and the same is sent to various levels for verification,
modification&finalapprovalinthehierarchicalorderlikeAssistantEngineer(A.E),Auditsection,
Divisional account officer (DAO), Executive Engineer. After the approval of the bill, a cheque is
issued. Application will facilitate to enter the bill details against which a cheque is issued. The
divisional accountant now prepares the account based on the reports & statutory schedules
generatedfromthesystem.
8.6.10.1. ProcessDescription:Works&ForestBillProcessing
Sl. STEP ACTOR
1 Junior Engineer (JE) prepares the bill in accordance with the

current schedule of rate & Administrative Approval against the
JuniorEngineer
project,basedontheestimatesandsendsthebilltotheAssistant
Engineerforverification.
2 AssistantEngineer(AE)verifiesthebillandnecessarymodification
AssistantEngineer
isdoneifrequiredandsendsthebilltoauditsection.
3 Audit section verifies the bill with the agreement and made
Auditsectionof
necessarycorrectionifrequiredandsendsthebilltotheDivisional
thedivision
AccountOfficer(DAO).
4 The DAO will check the bill with the available allotment/deposit
balance and forward it to Executive Engineer (EE) with a note in DAO
caseofanyexception.
5 ExecutiveEngineerverifiesthebillandmayapproveorrejectthe
ExecutiveEngineer
same.
Page|66

Sl. STEP ACTOR
6 Incaseifthebillisapproved,ExecutiveEngineerissuesacheque
ExecutiveEngineer
totheconcernagency/vendor.
7 Executive Engineer or Cashier can do a transfer entry (TE) for ExecutiveEngineer

necessarymodification,ifrequired. /Cashier
8 The EE/Divisional Officer may also cancel, an issued cheque if

ExecutiveEngineer
required.
9 An advice list based on the issued cheque, will be generated

automaticallythroughsystematthedayendandwillbeemailed System
toconcernbanks
10 Banksendsascrollforallthepaidchequesandthesameneedsto
be imported in iFMSOdisha, and accordingly voucher will be Treasury
generated
11 Thedivisionalaccountsofficerpreparestheaccountsbasedonthe
variousreportsandstatutoryschedulesavailableinthesystemin DAO
theprintableformatandsubmitsittotheA.G
8.6.10.2. Functionality:Works&ForestBillProcessing
Sl. Functionality
1 Systemshouldbeworkflowbased.Noonecanmodifyanydetailsifitisapprovedfrom
sameorhigherlevel.
2 Systemshouldfacilitatetheupperleveluserstodrilldowntheentireprocess.
3 System should facilitate the user to enter the master detail to generate monthly
accounts.
4 Systemshouldbecapabletovalidatetheavailableallotmentbalanceandvarioustypes
ofdepositbalanceduringbillprocess.
5 SystemshouldmaintainHOAandworkIDwisedepositbalanceanddeductionbalance.
6 Systemshouldbeabletogeneratecashbookbasedontheavailablebilldata.
7 System should be capable to maintain the OB & CB of various details like cash,
Deposits,TemporaryAdvance/Imprestandetc.
8 Systemshouldfacilitateusertopreparethemonthlyaccountsofthedivisions.
Page|67

8.6.11. eDisbursementofGovernmentClaims
Allthegovernmentpaymentsarewidelycategorisedintwoparts:
(I) Treasury drawl for all the DDOs. (Development of this module is already covered under
existing iOTMS. Test implementation is also complete. The module is to be rolled out
acrossstate)
(II) Cheque drawl for all the divisions. (This module needs to be developed afresh in iFMS
Odisha.Thishastobeimplementedatalldesireddivisions)
The process involves disbursement of government payment towards salaries, pensions, suppliers
etc.throughelectronicmode.
Incaseoftreasuryandchequedrawlthebills,alongwithbeneficiarydetails,receivedbyTreasury
officesorDivisionalofficersareprocessedforpayments.Incaseofsuccessfulprocessingofabill,
which is identified by approval given, to a bill/ cheque, it is forwarded for payments to the
beneficiarysbankaccountdirectly.
Theactivitywillbeasfollows:
PreparationofdigitallysignedelectronicpaymentadviceinCBS/NEFT/RTGSmode
OnlinedeliveryofeadvicetotheRBI.
OnlineconfirmationfromRBIonsuccessfulprocessingofeadvice
8.6.11.1. ProcessDefinition:
Sl. STEP ACTOR
CaseI:Onlineentry(Networkconnectivityisavailable)
TreasuryDrawl
Before submission of hardcopy bill to treasury, DDO will login into

iOTMSII system using proper credentials for entering the
beneficiarydetailsagainstaparticularbill DDO
ChequeDrawl
1
The divisions will login into the iFMSOdisha system using proper
credentials for entering the beneficiary details against a particular Divisions
bill.

CaseII:Offlineentry(Networkconnectivityisnotalwaysrequired)
DDO in case of treasury drawl will prepare the beneficiary list in a

prescribedexceltemplate.
Page|68

IncaseofOptionI,whilesavingthebeneficiaryinformation,system
willgenerateauniquereferenceIDforanyfuturereference.
TreasuryDrawl
2 DDOwillsubmitthephysicalbillandprintedbeneficiarylistwillbe DDO
attached as an annexure. DDO submits the physical bill to the
treasurywiththereferenceIDfortreasurydrawl.
In case of offline entry, DDO will manually send excel formatted

softcopyofbeneficiarylisttotreasuryalongwiththephysicalbill.
TreasurywillreceivethebillalongwiththerefIDmentionedinthe
hardcopybillfortreasurydrawl.
In case of offline option, treasury will capture the softcopy

3 beneficiarylistagainstthebill,providedbytheDDO,atthetimeof Treasury
billreceiving.
After successful receiving of the bill, it will be tagged with the

correspondingbeneficiarydetailsfortreasurydrawl.
TreasuryDrawl Treasury
BeneficiarydetailswillbeverifiedatthetimeofPayorderapproval
atalllevelofbillscrutinyhierarchy.
4
ChequeDrawl

Beneficiarydetailswillbeverifiedatthetimeoffinalapprovalatall
levelofbillscrutinyhierarchyatdivisionoffice. Division
EncryptedanddigitallysignedeAdviceinCBS/NEFT/RTGSmodewill
5 be generated. CePC will generate separate ECS for cheque and CePC
treasurydrawl.
eAdvice is sent online to RBI for crediting the amount directly to

6 CePC
beneficiarysbankaccountnumber.
On completion of eDisbursement process, RBI will send back the

7 digitally epayment scroll to CePC. RBI will send separate scroll for RBI
treasuryandchequedrawl.
Page|69

CePC will import the scroll and accounts will be generated
8 CePC
automaticallyforbothtreasuryanddivisionrespectively.
8.6.11.2. Functionality
Sl. Functionality
1 Systemwillbeaworkflowbasedsystem.
2 ProperITsecuritynormsmustbeappliedtotheapplicationforsecureOnlinetransaction
3 ThefacilityofOnlineentryofbeneficiarylistagainstaparticularbillshouldbeprovided
forbothOnlineBillSubmissionandManualBillSubmissioncases.
4 Whileenteringthebeneficiarylistonline,theremustbeafacilityforcopypasteoption
fromexcelfile.
5 SystemmustvalidatethebasicinformationoftheentrylikevalidIFSCcode,MICRcode,
equalityofbillgrossamountandsumofamountsofthebeneficiariesforthebilletc
6 TheremustafacilitytotakeaprintoutofthebeneficiarylistofaparticularbillatDDO/
Divisionend.
7 The system should capable to handle the digital signature, encryption and decryption
facility.
8 System shall facilitate the CePC to upload the eadvice to the RBI and to download e
scrolluploadedbyRBI.
9 SystemshallfacilitateRBItodownloadtheeadviceandtouploadescroll.
10 SMS/emailnotificationtothebeneficiarymustbeprovided.
8.6.12. OnlineBillPreparation&Submission
Usingthis moduleDrawingDisbursingOfficer (DDO),canprepareandsubmittheirbillsonlineto
the treasury. The DDO has to upload digitally signed scan copy of all the supporting documents
againstthepreparedbill.ApplicationwillallowtheDDOstocheckthepresentstatusoftheirbills
in treasury at any point of time. In case of any objection raised by the treasury, the DDO can
comply with the objection and resubmit the bills to the treasury. Also the module will provide a
utility to the DDOs for preparation of the bills in offline mode, upload the prepared bill to the
online module and then submit it through the online module. There can be several level of
approvalofthebillsbeforesubmittingittothetreasury.
8.6.12.1. ProcessDescription:
Sl. STEP ACTOR
1 DDOoperatorwillpreparethebillonlineorwiththehelpofoffline DDOOperator
billpreparationutility.AtthetimeofpreparationofbillstheHead
Page|70

Sl. STEP ACTOR
ofAccount(HoA)shouldbevalidatedwiththeiOTMSdatabase.
DDO operator would upload digitally signed scan copy of all the
supportingdocuments,andattachthemwiththebill.
After bill preparation, the bill will be submitted to the DDO for
approvalandsubmissiontothetreasury.
2 DDOwillcheckthebillandwillapproveorobjectthebill.
If the DDO approves the bill, the bill can be submitted to the
treasury. DDO
IftheDDOobjectsthebill,thebillwillbereturnedtotheoperator
forcorrection.
3 The operator will check and make necessary changes in the

returned bill and resubmits the bill to the DDO for onwards DDOOperator
submissiontothetreasury.
4 DDOwillsubmitthebillonlinetothetreasury.Asystemgenerated
treasurytokennumberwillbeassignedtothebill.
In this stage the DDO will take a printout of the submitted bill, DDO
which he has to submit in physical along with all the supporting
documentstothetreasuryfromwhereDDOdrawstheclaims.
5 Ifsomeobjectionisraisedbythetreasury,thebillwillbereturned
back to the DDO account. The DDO can make the necessary DDO
changesinthebilltocomplywiththeobjection.
6 Then DDO will resubmit the bill to the treasury. A new system
generated treasury token number will be assigned to the re DDO
submittedbill.
8.6.12.2. Functionality:
Sl. Functionality
1 System should be workflow based. A lower level user cannot modify a bill if it is
alreadyapprovedbythehigherlevel.
2 SystemshouldprovidetheeFormfacilitytopreparethebillofflineandsubmitthebill
online.
3 Systemwillfacilitatetheuserstoviewthestatusofthebillintreasuryatanypointof
time.
Page|71

Sl. Functionality
4 SystemshallnotallowtheuserstoprepareabillinanywrongHeadofAccount(HoA).
5 SystemshouldshowtheuserstatusofpendingallotmentamountiniOTMSatthetime
ofpreparationofbudgetedbills.
6 System should provide facility to the users to digitally sign and upload scan copy of
supportingdocuments
7 System should provide facility to match uploaded documents with checklist of

mandatorydocumentstobeattachedwithdifferentbilltypes.
8 Systemshouldprovidefacilitytotakeprintoutofdigitallysignedcopyoftheprepared
billaftersubmittingonlinetothetreasury.
9 AlltheprintedbillsmusthavewatermarkandQR/barcodeprintedonit.
8.6.13. OnlineOfflineBillPreparation&SubmissionModuleIntegration
ThisisaneformutilityusingwhichtheDrawingDisbursingOfficer(DDO),canpreparethebillinan
offlinemode.TheDDOcanpreparethebillandifrequiredhecansavethebillinhislocalPC.Once
thebillpreparationiscompletetheDDOcanuploadthecompletedbilltotheonlinemodulefor
onwardsubmissiontothetreasury.
Sl. STEP ACTOR
1 DDO Operator / approver prepare the bill using the eforms for
offlinebillpreparationutility.
Inthisstagetheusercansavethebillofflineforfuturereference. DDO
In this stage the user can draw reference from previously saved
offlinebill.
2 Oncethebillispreparedcompletelytheuserentershisuseridand
DDO
passwordandsubmitsthebilltotheonlinemodule.
3 Once the bill is saved in the online module a system generated

online reference id will be provided to the user. If some error
TreasurySystem
occurs(datavalidationetc.)thesystemwillconveythesametothe
user.
Sl. Functionality
Page|72

1 eforms application should be capable of interacting with the online bill preparation
moduletosubmitthedata.
2 Atthetimeofsubmissionofthebillfromofflinetoonlinethesystemmustcheckthe
correctnessofthebillHeadofAccount(HoA)andintegrityofthedata.
8.6.14. MobilebasedPaymentandTransactionReporting
Nowadays, Mobile payment and Mobile banking are some of the fast, convenient and secure
channels of payment and are being widely accepted by number of people. One of the major
advantagesistheavailabilityandusabilityofthedevice.
UserswillbeabletopaytheirtaxesandduesthroughthemobilebasedapplicationofePayment
8.6.14.1. ProcessDefinition:MobilebasedPaymentandTransactionReporting
Sl. STEP ACTOR
Tax payers/ Depositors needs to download the ePayment mobile

application. After downloading the same they will install the

applicationintheirmobile.
User needs to provide a PIN number at the time of installation
whichwillbeusedasapasswordwheneveruserwantstologinto
themobileapplication.

At the time of installation the application, user needs to provide TaxPayers/
1. any Unique Identification Number of concerned department like Depositor
forTIN/SRINofCommercialTaxDepartment,RegistrationNumber
forMotorVehiclesdepartmentetc.Thiswillhelptodownloadthe
detailsonlineabouttheTaxpayers/Depositorandinformationwill
storeintheMobiledevice.
IfuserdoesnothaveanyUniqueIdentificationNumberthenthey
need to provide all the key information like TIN/SRIN etc. at the
timeofeachpayment.
2.
Atthetimeofonlinepaymentachallanreferenceid(Uniqueinthe
TaxPayers/
application) will be generated and will be transferred to the user
Depositor
throughSMS.
3.
Taxpayers/DepositorscanpaytheamounteitherthroughMobile TaxPayers/
BankingorNetBanking. Depositor
4.
Thechallangeneratedonsuccessfultransactionwillbeemailedto
theregisteredmailidofthedepositor,ordepositorcanalsotakea TaxPayers/
print of the challan later from the treasury portal by using the Depositor
uniquechallanreferenceid.
Page|73

8.6.14.2. Functionality:MobilebasedPaymentandTransactionReporting
Sl. Functionality
1 ThesystemshouldbecapabletogenerateUniqueChallanReferenceID.
2 Thesystemshouldbecapabletolistallthetransactions(saylast10transaction)along
withtheirstatusagainstaparticularPIN
3 SystemshouldbecapabletogenerateautomaticeMailforgeneratedchallan.
4 SystemshouldbecapabletogenerateSMSforchallanreferenceid
8.6.15. Financialdatawarehouse&BudgetDecisionSupportSystems(BDSS)and
BusinessAnalyticandIntelligenceSystem
After implementation of iOTMS, significant benefits have accrued from transaction processing
systemandthemanagementinformationsystem.iOTMShascollectedsignificantamountofdata,
Thequantityofdatawillincreaseastimepasses.
Thisdatacontainsimportantknowledgewhichgoesunusedduetolackoftechnologyandanalysis
andrepresentation.
System will allow accessing of Budget Decision Support Systems (BDSS) to the different level of
userstoaccessandanalyzethehistoricalinformationagainstthecurrentyearactual.Thiswillhelp
totake efficient decision ateach level (CO/HOD, AdminDepartments (ADs), FinanceDepartment
(FD)andP&CDepartmentforfinalizationofvarioustypesofestimate.
BDSS helps users to generate Analysis View (Drill through/Drill down), Analyzer Reports (Drill
through/Drill down), Dash Board, Adhoc Reports and Receipt/Expenditure forecasting for next
financialyear.
User can drill through/drill down Financial Year, Service, Demand Number, Plan, Charge_voted,
DDO, Major Head, SubMajor, Minor, SubHead, Detail & Object Head wise expenditure/receipt
budgetofthestate
8.6.15.1. Functionality:BDSS
Sl. Functionalities
1 System shall allow accessing of Budget Decision Support Systems (BDSS) to the
different level of users to access and analyze the historical information against the
currentyearactual.
2 System shall provide Drill through/Drill down, Analyzer Reports (Drill through/Drill
down), Dash Board, Adhoc Reports and Receipt/Expenditure forecasting for next
financialyear.
3 Systemshallprovidefacilitytoproducethereportbyprovidinganytypeofparameters
likeyearwise,monthwise,weekwiseorheadwise.
Page|74

Sl. Functionalities
4 Systemshallallowuserstoundertakepayment&receiptestimationfacilitatedbythe
scientifictoolsandlaiddownformulasincluding:
Trendanalysis
Projectiontools
Previousyear(s)collection
Industrytrend,etc.
5 SystemshallfacilitatecomputationofDebtrequirementbyusingBusinessIntelligence
ToolsanddataavailableiniFMSOdishadebtModule
8.6.16. OnlineAudit&Inspection
AGAuditcarriesouttwokindsofaudit:AccountAuditandTransaction/VoucherAudit.
Further,InternalAuditWingconductsregularauditofDepartmentsofGovernmentofOdisha.
Therefore,themainprocessofAuditisdividedintothreesubprocesses:
AccountsAudit
Transaction/VoucherAudit
AuditbyInternalAuditWing
AG(Audit), and Internal AuditWing shallapply theirexisting policies,practiceandprocedurefor
conducting audit. Tobe audit process shall only automate the interface of AG (Audit)/ with FD/
DTI/Departments.
8.6.16.1. ProcessDefinition:AccountsAudit
The Accounts audit is carried out by AG (Audit) for both Finance Accounts and Appropriation
Accounts prepared by AG (A&E). AG (Audit) shall apply their existing policies, practice and
procedureforconductingaudit.TobeauditprocessshallonlyautomatetheinterfaceofAG(Audit)
withFD/AG(A&E).
Sl. STEP ACTOR
1 AGAuditteamshallaccessFinanceandAppropriationA/cthrough AGAudit
theSystemandconductauditaspertheirrulesandguidelines.
2 Audit team shall record its observations in the form of Audit

Memos and send them to concerned official i.e. FD/ DDO/ DTO/
AGAudit
STOthroughiFMSOdishaportal.

The System shall have facility to map audit paras with replies and
alsototrackpendingauditparas.
3 FD/DDO/DTO/STOenterstheirresponseagainsttheauditqueries FD/DDO/DTO/
Page|75

Sl. STEP ACTOR
and if required submit an alteration memo for making necessary STO

correctionintheA/c

4 AG (A&E) enters the necessary transfer entries into the System

AG(A&E)
basedonAlterationMemo.
5 Upon receiving satisfactory responses/ comments from FD/ DDO/

DTO/ STO/ PAO, AG Audit certifies for Finance Accounts and
AGAudit
Appropriation Accounts and sends the same to CAG for
certification.
6 CAG certifies the Finance and Appropriation based on the CAG

certificateprovidedbyAG(Audit).
7 CertifiedAccountsarelaidbeforelegislativeassembly. AG
8.6.16.2. ProcessDefinition:Transaction/VoucherAudit
The audit is carried out by AG (Audit) for the transaction undertaken by the Department. AG
(Audit)shallapplytheirexistingpolicies,practiceandprocedureforconductingaudit.Tobeaudit
processshallonlyautomatetheinterfaceofAG(Audit)withDepartments.
Sl. STEP ACTOR
1 AG Audit team prepares Audit Plan and informs it to respective

Audit teams. Audit teams based on the Audit plan prepare audit
requisitionslist. AGAudit
This list shall be uploaded into iFMS II portal, accessible by
respectiveDepartment.
2 Audit teams visit the respective DDO/ DTO/ STO and carry out
Audit.
They record their observations in the form of Audit Memos and
shall send them to respective DDOs for their comments through
AGAudit
iOMSII.
DDO
TheSystemshallhavefacilityto:
Mapauditparasagainstaparticulartransaction.
Mapauditmemoswithrepliesandalsototrackpendingaudit
memos.
3 DDO/ DTO/ STO shall also provide their responses through the
AGAudit
System,accessiblebyAG(Audit).
Page|76

Sl. STEP ACTOR
Based on the comments of the DDO/ DTO/ STO, AG Audit

consolidates the audit observations and shall send them to Public
AccountsCommitteethroughiOTMS.
4 PublicAccountsCommitteeshallreviewtheauditparaandmarkit
torespectiveHOD/Adm.Secforrequestingresponsethrough the PAC
System.
5 HOD/ Adm. Sec provide their replies to AG Audit through the

System,accessiblebyAG(Audit).
AGAudit
Based on the responses of HOD/ Adm. Sec, AG Audit prepares a
HeadofOffice
statement ofcritical auditparas. The statement of critical paras is
senttoC&AG.
6 C&AG compile and generate Audit report, containing critical audit

paras. Audit report is then laid down before the Legislative
C&AG
Assembly.AcopyofAuditreportshallalsobeuploadedoniOTMS
portal.
8.6.16.3. ProcessDefinition:InternalAudit
TobeauditprocessshallonlyautomatetheinterfaceofInternalAuditWingwithDepartmentsof
GovernmentofOdisha.
Sl. STEP ACTOR
1 Internal Audit wing will access iFMSOdisha to view transaction InternalAudit

detailspertainingtoAuditeeAgenciesbasedonrequirement Wing
2 ConductsAuditaspertherequirementsofrulesandregulationand
uploadtheAuditReportoniFMSOdisha. InternalAudit
eMailnotificationissenttorespectiveauditeeagenciestofurnish Wing
theirresponsesagainstauditpara
3 AuditeeAgenciesshallfurnishresponsestotheAuditqueries/para Auditee
raisedbyInternalAuditWing Agencies
8.6.16.4. Functionality:OnlineAuditandInspection
Sl. Functionality
1 SystemshallhavetheprovisionforAuditTeamtouploadtheauditprogram.
2 Systemshallhavetheprovisionofautointimatingtheunits/officescoveredunderthe
Page|77

auditprogram.
3 SystemshallhavetheprovisionforAuditTeamtoenterthelistcontainingrecordsto
beexaminedduringinternalauditbasedonitsexistingpolicies.
4 Further,thesystemshallprovidelimitedaccesstoAuditTeamofthereports/registers
requiredtocarryoutInternalAudit.
5 System shall have provision to provide access to Audit team for carrying out System
Auditi.e.auditofcomputerizedrecord
6 System shall facilitate Audit Team to access audit trail of transactions/ transactions
lifecycle.
7 System shall have provision for Audit Team to prepare/ upload Inspection report/
AuditReport.
8 System shall have provision for auto email/ SMS alerts (as applicable) to concerned
officialswhereinauditparasareoutstandingbeyondapredefinedtimeframe.
9 SystemshallhaveprovisionofuploadingtheAuditreport.
8.6.17. OnlinePaymentrequestfromPLoperator
Thisprocessinvolvestwomajoractivities:
OnlineCreationofanewPLoperator
ItwillbeaworkflowbasedprocessforcreationofnewPLoperator.HeadofDepartment
willrequestAdministrativeDepartmenttocreateaPLoperatorwhointurnapprovesthe
request. The approved request with all necessary information will be transmitted to
treasury for creation of new PL operator. Treasury will generate the new PL operator ID
andconcernedagencieslikeAG,Departmentetcwillbeinformedaccordingly.
OnlinepreparationandsubmissionofPLpayment
This functionality will automate the PL payment process. Through this functionality PL
operator will prepare claim online and submits the same to treasury electronically.
Treasury will process the claim and send epayment advice to bank for payment of the
claim.
8.6.17.1. ProcessDefinition:OnlineCreationofaNewPLOperator
Sl. STEP ACTOR
1 HeadofdepartmentwillloginintoiFMSOdishatoinitiaterequest
HoD
forcreationofnewPLoperator
2 The request will be forwarded to administrative department to

HoD
approveit.
Page|78

Sl. STEP ACTOR
3 Admindepartmentscrutinizestherequestandapprovesitthrough
system.Admindepartmentalsoprovidesnecessaryinformationlike
CoA to be linked with the new operator, designation of the AD
operator, linked treasury name, PL operators bank account
number,IFScodeetcrequiredforcreationofnewoperator
4 Admin department forwards the approval to the respective

AD
treasurytocreatetheoperator
5 TreasurywillgeneratetheUniqueIDforthenewoperator. Treasury
6 Treasury will intimate the new operator id to concerned agencies

Treasury
likeAG,Admindepartment,Headofdepartment
8.6.17.2. ProcessDefinition:OnlinePaymentRequest
Sl. STEP ACTOR
1 PLoperatorwilllogintothesystemtogeneratepaymentrequest PLOperator
2 PL operator enters the required information for payment and

generates the payment request. Unique reference ID will be
generatedforfuturereference. PLOperator
3 Treasurywillverifytheauthenticityofthepaymentrequest,check
Treasury
availabilityoffunds,processandapproveit.
4 Treasurysenddigitallysignedencryptedepaymentadviceonlineto
bankinNEFT/CBS/RTGSformatfordepositoftheclaimamountto Treasury
thebeneficiarysbankaccountnumber.
5 Bank decrypts, verifies the digital signature and deposits the

amount in line with payment advice to beneficiarys account LinkBank
number
6 Banksendsescrollonlinetotreasuryforaccounting LinkBank
Sl. Functionality
1 Systemshouldbeaworkflowbasedsystem.
Page|79

2 Proper IT security norms must be applied to the application for secure Online
transaction
3 SystemshouldbecapabletointegratewithAG,LinkBankforaccountstransferand
forpaymentrespectively
4 System must validate the basic information of the entry like valid IFSC code, MICR
code,checkingofallotmentetc
5 Thesystemshouldcapabletohandlethedigitalsignature,encryptionanddecryption
facility.
6 System shall facilitate the treasury to upload the eadvice to the link bank and to
downloadescrolluploadedbylinkbank.
7 Systemshallfacilitatethelinkbanktodownloadtheeadviceandtouploadescroll.
8 SystemshouldbecapabletogenerateSMS/emailnotificationtothebeneficiary.
9 Different types PL expenditure related reports must be generated through the

system
8.6.18. VirtualTreasury(CyberTreasury)
This functionality deals with the electronic receipt of Government taxes and dues such as
Commercial Taxes, Mining Royalties and Fees, Motor Vehicle Tax, RTI Application Fee etc. The
CyberTreasury,createdsinceFebruary2010,isresponsibleforonlinereceipts.
Business process has been reengineered in order to facilitate the depositor, to deposit their
challan from anywhere using net banking facility, without the physical presence through SSL
securedportal.Tillnow40public,privatebankshasbeenintegratedwithiOTMS.Morethan40%
of the Government revenue is now being collected through the Cyber Treasury. However this
facilityislimitedonlytotheoperatorsofnetbanking.
Toextendthisfacilitytoallcitizens,analternativeOfflineChallanSubmissionmodelissuggested
in addition of net banking facility. In this model, depositor will get a filled challan form with a
uniquechallanreferencenumber,afterprovidingnecessaryinformation,throughDTIportal.Atthe
timeoffillinginformation,hehastoprovidethepreferredbanknamewherehewantstodeposit
the challan amount in cash/ cheque. He submits the system generated filled challan form along
withcash/chequetotheselectedbanktodeposithistax/dues.Bankreceivestheamountagainst
thechallanreferencenumberandsendsereceivescrolltocybertreasuryforaccounting.
8.6.18.1. ProcessDefinition:CyberTreasury
Sl. STEP ACTOR
1 DepositorlogontoOdishaTreasuryPortal Citizen
Page|80

Sl. STEP ACTOR
2 Depositorhastochoosedepartmentspecificchallanorgeneral
Citizen
challanoption.
3 Depositorfillschallanspecificinformationthroughsystem Citizen
4 Depositor choose payment mode which will be Cash/Cheques

Citizen
Paymentmode
5 DepositorchoosebankName Citizen
6 SystemgenerateschallanreferenceIDforanyfuturereference System
7 ForCashPaymentmode,systemwillgeneratesafilledupprintable
challan form with challan reference id and the data will be System
transferredtotheselectedbankportalautomatically.
8 Depositor will take the printout of the challan form, submits the Citizen
samewithcashorchequetotheselectedbankwithinapredefined
timeperiod.
9 In case of Cash/cheque Payment mode, Bank will collect the

amount/cheque against the challan reference ID. Bank issues an
acknowledgement to depositor. Bank also sends successful Bank
payment information batch wise to cyber treasury at an agreed
frequency.
10 BanksendsereceiptscrolltoRBI. Bank
11 RBI consolidates escrollsreceived from different banksand sends

RBI
oneconsolidateddigitallysignedescrollonlinetocybertreasury
12 Cyber treasury imports the escroll. The challan number and

CyberTreasury
subsequentlyaccountsisgeneratedautomatically.
13 AGdownloadstheeaccountsonline. AG
8.6.18.2. Functionality:CyberTreasury
Sl. Functionality
transaction.
2 Integration is required with multiple banks, RBI, AG, other departments like Mining,
Transportetc.
Page|81

3 System based validation of entered information like chart of account, TIN/SRIN

number,etcisrequired.
4 Thesystemshouldcapabletohandlethedigitalsignature.
5 Thesystemshouldcapabletohandlepaymentagainstmultiplechartofaccount.
6 Multiplelinkbankfacilityforcybertreasurymustbeprovided.
8.6.19. NPSincludingESSfortheNewEmployees
Thismoduledealswith2functionalities:
CaptureandprocessingofPRANgenerationrequestfornewstateemployees
EmployeeSelfService(ESS)forthenewemployees
Using PRAN generation request functionality, system will receive and process the PRAN
generation request from DDO for the new state employees. Treasury will send the DDO wise
consolidated PRAN generation request to NSDL system. Treasury will intimate the new PRAN
receivedfromNSDLtoDOO.
ESS(EmployeeSelfService)willhelpthenewstaterecruitswhocontributetowardsNPStoinitiate
onlinerequestforseveralactivities.OnesuchactivitywillbeonlinesubmissionandprocessofS2
form where employee can send request to change his/her personal information stored in NSDL
server.Employeecanalsoqueryseveralrelatedinformationlikehis/herNPScontributiondetails,
Governmentcontributiondetails,Personalinformationetc.
Sl. STEP ACTOR
1 NewemployeewilllogintothesystemusingESSfunctionality,and Employee
will send PRAN generation request with necessary information to
DDO.
2 DDOwillvalidateandsendtheapprovedrequesttotreasury DDO
3 Treasurywillperformsomebasicchecks,consolidatesDDOwise
Treasury
PRANgenerationrequestsandwillsendthesametoNSDL
4 NSDL will receive the consolidated request from treasury and

NSDL
generatesthePRANandwillintimatethesametotreasury
5 NewPRANwillbeavailabletoDDOandsubsequentlyEmployeecan
gethisPRANthroughESSfunctionality. Treasury

6 Employee submits S2 form online to request to change his/her Employee
Page|82

Sl. STEP ACTOR
personalinformationstoredinNSDLserver
7 Employeecanalsoqueryseveralrelatedinformationlikehis/her Employee
NPScontributiondetails,Governmentcontributiondetails,Personal
informationetc.
Sl. Functionality
transaction.
2 SystemshouldbecapabletointegratewithNSDL
3 Systembasedvalidationlikeduplicaterequestchecketcisrequired.
4 ThesystemshouldcapabletogenerateuniqueacknowledgementIDatvariousstages
ofrequestsubmission.
5 SystemshouldcapabletogenerateMISreports
8.6.20. CentralizedNPSContributionUploading
ThisfunctionalitywillbeavailablefortheusersofcentralizedNPScellatDTI.Thismodulewillbe
usedtocentrallygenerateanduploadthestatewiseNPScontributioninformation(bothemployee
andGovernmentcontribution)toNSDL,Centralrecordkeepingagency.NPScellcanmonitorthe
state wise NPS contribution status and can generate alerts through this module. Existing iOTMS
systemneedstobecustomizedforthisfunctionality.
Sl. STEP ACTOR
1 DDOwillprepareemployeewiseNPScontributionscheduleatthe
time of salary bill preparation using any of the following two
options:
Using HRMS System: DDO will prepare salary bill through

DDO
HRMS system. HRMS will generate employee wise
contributiontowardsNPSalongwithotherschedules.This
NPScontributioninformationwillbestoredinXMLfilefor
onwardtransmissiontotreasuryalongwithsalarybill.
ManualSystem:InabsenceofHRMSsystem,DDOprepare
salary bill manually or through other 3rd party system. In
Page|83

Sl. STEP ACTOR
this case, DDO prepares the NPS contribution schedule in

preformattedexcelfileandsubmitthesoftcopyandhard
copyofthescheduletotreasurymanuallyalongwithsalary
bill.
2 Treasury receives NPS schedules from DDOs either through HRMS

ormanually.
HRMSSystem:
o After preparation of salary bill, all bill related
information, including NPS schedule, will be
transmitted to central server of iFMSOdisha through
FTP.AllinformationwillbeinXMLformat.
o HRMSsendsDDOwisebillinformationforallapplicable
treasuries of the state to central server. System will
periodically check the availability of the new files
coming from HRMS. System will validate first the bill HRMS,
information using different types of validation rules. If Application,
everythingfoundok,thenthesamewillbeimportedto Treasury
treasurysystem.

o Thebillinformation,includingtheNPSschedule,willbe
availabletocorrespondingtreasuryusersforprocessing
of the bill. No need to enter or manually import the
NPS schedule at treasury level. Everything will be
populatedfromcentrallocationfromXMLfilessentby
HRMS.
Manual System: Treasury user receives the soft copy of NPS

schedule, prepared by DDO, through pen drive or CD. This
informationwillbecapturedatthetimeofbillreceive/process
by front desk clerk at treasury. System will automatically tag
theschedulewiththecorrespondingbill.
3 Treasuryprocessesthesalarybills.Atthetimeofbillprocessingthe
NPSamountwillbetransferredtoaparticularBTheadspecificfor
Treasury
EmployeesNPScontribution.Treasurywillsendadvicetobankfor
paymentofsalary.
4 Afterpayment,Bankwillsendpaymentdetailsasapaymentscroll
totreasury.Treasurycompletestheaccountwithinaspecifiedcut Treasury
offdate.
5 After completion of accounts of all treasuries, DTI central location iOTMS
Page|84

Sl. STEP ACTOR
will consolidate all the NPS schedules captured at individual application/DTI

treasuriesandgeneratesonesingleNPSfileinaprescribedformat Centrallocation
thatneedtobeuploadedtoNSDL.
6 BeforeuploadingtheNPSfiletoNSDL,itwillbevalidatedbysome Employee
mechanism(Utility)providedbyNSDL.
7 After successful upload of employees NPS contribution to NSDL,

iOTMS application will capture the transaction number of the file
uploadprocesssentbyNSDL.
SystemwillgeneratetheGovt.Contributionbillwhichwillbeanil iOTMS
bill with major head 2071 whose gross amount is equal to the Application
employee wise consolidated NPS contribution, uploaded to NSDL,
amount.Thewholegovt.contributionistransferredtoaparticular
BTheadspecificforGovt.NPScontribution.
8 This system generated bill will be transmitted to On line bill

preparationandsubmissionmoduleforonlinesubmissionofthe
DTICentral
billbyDDOtothecorrespondingtreasury.Beforesubmission,DDO
locationasa
cancheckthedetailsofthebill.DDOwilltakeprintoutofthebill
DDO
after on line submission and submits the hard copy to treasury
manually.
9 Treasuryprocessesthebillandapprovesit. Treasury
10 System will auto generates two bills. One is for employee

iOTMS
contribution(storedatspecifiedBThead)andtheotherisforGovt.
application
Contribution(StoredatSpecifiedBThead).
11 ThesetwobillswillalsobetransmittedtoOnlinebillpreparation DTICentral
andsubmissionmoduleasdescribedinstep8 locationasa
DDO
12 Treasuryapprovesthetwobills. Treasury
13 CePCsendsRTGSadvicetothedesignatedbankforpaymentwith
CePC
thetransactionnumbercapturedatstep7.
14 AftergenerationofTVnoatTreasury,themappingofTVnowith DTICentral
NPSschedulewillbetransferredtoNSDL. location
Sl. Functionality
Page|85

transaction.
2 SystemshouldbecapabletointegratewithNSDL.
3 System must maintain PRAN master data. DDO registration information must be
availableinthesystem.
4 Synchronization with NSDL is required for periodic updation of different types of

masters.
5 SystemmustvalidatealltheNPScontributiondatalikeDDOregistrationno,PRANno,
Employee contribution amount etc at the time of capturing of NPS schedule at
treasury.
6 There mustbea mechanismtovalidatetheNPScontributionschedule,generatedat

centrallocation,beforeuploadingthesametoNSDLsystem,sothat100%errorfree
filecanbeuploaded.
7 Theremustbeaqueryfeatureusingwhich,DDOandemployeescanmonitortheirNPS
contribution.
8 SystemshouldraisealertincaseofnoninclusionofanemployeeintheNPSschedule.
9 TheremustbeareconcilemechanismwithNSDLsystemregardingtheemployeewise
NPScontribution.
10 SystemshouldcapabletogeneratedifferenttypesofMISreports.
8.6.21. SanctionOrderDatabaseModule
CertainbilltypessuchasOCF,GIA,ACBILL,GPF,MCA,HBAetc.requiredthesanctionordertopass
thebill.Totalamountofbillshouldnotexceedthesanctionamount,andalsothebillcouldnotbe
passedafterthevalidityperiodisover.AG(O)officewilllatercheckthesanctionorderforsuchbill
types.TheiFMSOdishashouldhavefacilitytocapturethesanctionorderandtotagthesamewith
thebillattimeofsubmission.
Sl. STEP ACTOR
1 Department will enter the sanction details in the system. This will
includeamountsanctioned,nameofthebeneficiaries,thedatethis
sanctiontillvalid.Presentlytherearedifferentformatfordifferent Department
types of sanction. These sanction order format needs to be
categorisedinordertomakeacommonformatforeachcategory.
Page|86

Sl. STEP ACTOR
2 Atthetimeofissuingsanctionorderbythedepartment,aunique Automatic&
sanctionidwillbegeneratedthroughapplication. Department
3 Theconcernedbeneficiaryofthesanctionwillbeinformedonline,
with a reference of the sanction id. A sanction letter can also be Department
generatedthroughthesystem.
4 DDO will quote the sanction id with the bill, at the time of
submission at treasury. He/she need not to endorse the sanction DDO
orderwiththebill
5 Treasury would validate the quoted sanction id with the sanction

Treasury
database,whilepassingthebill.
6 Treasury will also validate the bill with the sanction amount,
sanctionvalidatetilldate.Itwillalsoensurethatcumulativedrawl
in different phase against a single sanction, does not exceed the Treasury
sanction amount. For any exception proper message will be
generatedandwillbeconveyedtotherespectiveDDO
7 AG(O)willcheckthebillagainstthesanctionorderquotedthrough
AG(O)
aninterfaceprovidediniOTMSapplication
Sl. Functionality
1 Systemshouldbecapabletoprovideaninterfacetodepartmentinordertocapturethe
sanctioninformation.
2 Systemshouldbecapabletoparameterisethesanctioncategoryandgroupsimilartypes
ofsanctionagainstthebilltype.
3 Systemshouldbecapabletogenerateuniquesanctionidforeachsanction.
4 Systemshouldbecapabletoinformthebeneficiaryaboutthesanctionordergenerated.
5 System should be capable to generate sanction letter for each sanction order, as and
whenneeded.
6 The sanction ID must be available to concern DDO, in order to quote it, with the bill
throughtheapplication.
7 System should be capable to validate the bill amount and date with the sanctioned
Page|87

amountandsanctionvalidtilldateattimeofbillprocessingintreasury.
8 System should be capable to ensure that cumulative drawl in different phase against a
singlesanction,doesnotexceedthesanctionamount.
9 SystemshouldbecapablegeneratepropermessageandconveyedittotheconcernDDO,
incaseofanyexception.
10 System should be capable to provide an interface for AG(O) to check the bill and the
quotedsanctionorder.
IntegrationofiFMSOdishawithexistingapplicationiOTMS
8.6.22. TreasuryBudgetPlanning&DSSModuleIntegration
Budget Planning & Preparation and DSS modules will be introduced in iFMSOdisha. In order to
makethesemodulesintegratedandconsistentwiththeexisting(iOTMS)applicationandtogetrid
ofdataentryerror,customizationoftheexistingsoftwareisrequiredanddatasharingpointneeds
tobeestablishedwiththecoreapplication.
Sl. STEP ACTOR
1 Approvedbudgetfrombudgetpreparationmodulewillbeavailable
in existing applications budget distribution module, for all DTI
departmentsaspertheirdemandforgrants.
2 Systemshallupdateaccountheadmasterandcombinationmaster
Automatic
automaticallyduringbudgetperpetration.
3 iFMSOdisha data ware house database need to be configured to

store historical data from AG, P&C Department, Planning
Commission,HRMISandiFMSOdishaOLTPsystem. DTI,AG,HRMS,
HoAwiseactualexpenditureandreceiptofpreviousfinancialyears P&CDept,
needtobeavailableiniFMSOdishawarehousedatabase. Planning
Commissionand
HoAwiseloanreceivedandrepaymentandhistoricaltrendneedto Budget
beavailableiniFMSOdishawarehousedatabase. Preparation
These data is required for Budget Preparation as well as DSS
modules.
4 SomeHRMSdataneedtobeavailableiniFMSOdishapensionand Budget
salaryexpenditureprojectionofcomingfinancialyear. Preparation,
ThiswillhelptotakedecisionduringbudgetpreparationandDSS. DSS&HRMS
5 Treasuryonline(current)transactionaldataneedtobeavailablein Automatic
Page|88

Sl. STEP ACTOR
budgetpreparationmodule.
6 NewHoAanddepartment&HoAwisebudgetamountneedtobe
availableinexistingapplicationsBudgetDistributionandtobeDSS
Automatic
modules on approval of a budget (may be Annual, Vote on
AccountsorSupplementary)byHonourableGovernoroftheState.
SL. FUNCTIONALITY
1 Systemshouldbecapabletocapturemasterdata(namelymodules,users,menus,etc...)
requiredforbudgetpreparationandDSSmodule.
2 SystemshouldbecapabletouploadFinanceAccountsandloanrelateddatabytheAG
user. During upload process proper versioning and logs would be maintained to avoid
theduplicityofafileaswellasdata.
3 System should be capable to upload HRMS data by the HRMS user. During upload
processproperversioningandlogswouldbemaintainedtoavoidtheduplicityofafile
aswellasdata.
4 System shouldbecapabletoimportdatareceived fromAG,HRMS,P&CDepartment

and Treasuries data from OLTP system into iFMSOdisha data ware House database.
Duringthisimport,systemshouldvalidatetheavailabilityofallrequiredmasterdatain
iFMSOdisha. Proper message should be generated through the system in case of any
exception.
During import process proper versioning and logs would be maintained to avoid the
duplicityofdata.
5 System should be capable to generate proper message and make it available with
concernedauthority.
6 Existing master maintenance module, namely user, menu, user wise menu access, etc
need to be customized to accommodate new functionalities of Budget Planning and
PreparationandDSSmodules.
7 ExistingHeadofAccounts(HoA)andothermasterdata(namelydepartment,CO,DDO)
willbeavailableinBudgetPlanningandPreparationandDSSmodule.
8.6.23. PaymentTPFModuleintegration
TPFmoduleisintroducediniFMSOdisha.Inordertomakethismoduleintegratedandconsistent
with the existing application and to get rid of data entry error, customization of the existing
softwareisrequiredanddatasharingpointneedstobeestablishedwiththecoreapplication.
Page|89

Sl. STEP ACTOR
1 DDOwillsubmitthebillattreasury.Forthesalarybill,TPFschedule
needs to be identified and should be matched automatically with DDO/Treasury
thetotalbytransferamount.
2 TPF details will include subscriber account number and series. At

thetimeofimporttheaccountnumberandseriesmustbechecked
Automatic
with themaster data available inthedatabase. A propermessage
needstobecapturedincaseofanyexception.
3 TheaccountnumberandseriesmustbemaintainedinTPFmodule
itself. Presently the data maintained at treasury level must be Automatic&
validatedandcrosscheckedwiththeTPFmoduledataandneedsto Treasury/CoA
beobsoletefromacertaincutoffdate.
4 For debit sanction against a TPF subscription, sanction letter and

Finance
othernecessarydatamustbemaintainedinthesystem.
5 At the time of bill passing at treasury, the certain bill for debit
sanction must be checked against the sanction order available. Treasury
Propermessageshouldbegivenforanyexception.
6 Incaseofanyexceptionmentionedabove,mustbenotifiedtothe
Automatic
concernedauthoritytomakefurtherdecision/rectification.
7 DebitsanctionTPFbillapprovedbythetreasurymustbeavailable
Automatic&
in TPF module along with the sanction letter in order to maintain
CoA
thesubscriberwiseTPFaccount
8 Thefinalpaymentatthetimeofsuperannuationwillbecalculated
bytheCoA.Theamountcalculatedatthetimeoffinalpaymentand
Treasury
the final payment order will be checked by the treasury online in
ordertopassthefinalpaymentbill.
9 Apart from the subscription amount the debit amount deducted

against the loan taken is deducted through salary. At the time of Automatic&
processingthesalarybillattreasury,thedatamustbesharedwith CoA
theTPFmoduleinordertokeeptrackofthedebitsubscription.
SL. FUNCTIONALITY
1 System should be capable to import the schedule available with the salary bill
Page|90

SL. FUNCTIONALITY
automatically
2 System should be capable to perform necessary validation like account number and
seriesatthetimeofimport.Propermessageshouldbegeneratedthroughthesystem
incaseofanyexception.
3 Systemshouldbecapabletousethedataavailableintreasury,withoutanyduplicate
entryatTPFmoduleandviceaversa
4 System should be capable to generate proper message and make it available with
concernedauthority.
8.6.24. iOTMSPortalMobileBasedTaxPaymentIntegration
Inordertofacilitatemobilebasedpaymentfewchangestotheexistingportalneedstobemade.
Existing application should provide services in terms of sharing relevant data and accepting the
samefromthemobileapplication.
Sl. STEP ACTOR
1 Mobile application for online tax payment needs to validate the

data like TIN/SRIN of Commercial Tax Department, Registration
Automatic
Number for Motor Vehicles department etc. This data is available
withexistingapplicationdatabase.
2 Existing application will generate a unique reference number for

Automatic
eachchallanandwillbenotifiedtouserthroughSMS.
3 Existing application will keep track of successful, failure and

pending bank transaction status as available from mobile based Automatic
application.
4 On successful transaction the existing application will generate a

challan and will send it to the concerned user email id. Also the Automatic/
depositor can get a printout of the challan from the portal, by Depositor.
providingthechallanreferencenumber.
SL. FUNCTIONALITY
1 Existingapplicationshouldbecapabletoprovidealinkintheportal,fromwhereuser
candownloadandinstallthemobilebasedapplication.
Page|91

2 Existing application should be capable to share relevant data with the mobile based
application.
3 ExistingapplicationshouldbecapabletocommunicatethroughSMSandemail.
8.6.25. PaymentEDisbursementModuleIntegration
DDO will prepare and submit bills online. Existing iOTMS application needs to be customized in
ordertoincorporatetheonlinebillsubmissionfunctionality.
Sl. STEP ACTOR
1 Token number will be generated from the existing application at

thetimeofbillsubmissionbyDDO.DDOwillsubmitthebillonline Automatic&
along with the beneficiary details, with necessary information for DDO
directcreditofaccounttobeneficiarybankaccountnumber.
2 Treasury will pass the bill and will have an option to approve the
advice to pay either through treasury link bank or through RBI.
Treasury officer can change the payment order through link bank
Treasury
forcertainbilltypesonly.Thesebilltypesshouldbeparameterised
in system. The advice for link bank, generated locally by the
treasury.
3 CPPC will generate the advice centrally for all treasuries and the
samewillbeavailableatRBI.Theadvicewillcontainthetwofiles
oneismandateandanotherisECS.ECSfilewillcontainthedetailof CePC
beneficiaries.Theamountwillbecreditedtobeneficiariesaccount
directly.
4 RBI will send the debit scroll mentioning the transaction status
either success or failure (in case of failure the reason for failure
mustbeincluded).CePCwillimportthescroll.Fortheunsuccessful CePC
transactions beneficiary wise challan will be generated against
suspensehead.
5 The concerned DDO will be communicated about the failure

transaction and will be given a provision to correct the DDO
beneficiariesaccountrelatedinformation.
6 Every day a scheduler will run to check the DDOs correction and
Automatic
willgenerateabillagainagainstthesystemgeneratedchallan.
7 This system generated bill will be available in treasury officers Automatic

login.Whointurnwillsubmitthebilltoowntreasuryandatoken
Page|92

Sl. STEP ACTOR
number will be generated. Treasury officer will also take a print

outofthebillandwillsubmitthesame.
8 Bill will be processed in treasury and advice will be send again by

Treasury&CePC
CePCtoRBI.
9 Existing application needs to provide the payment information

alongwiththechallan(generatedforunsuccessfulpayment)online
toAG(O)in.
Treasury
Treasury application also needs to provide the payment made
further based on the challan generated for unsuccessful
transaction.
ChangesneededinAGVLCsoftware
10 AG(O)willkeeptrackofthesuspenseandtheirclearancebasedon
AG(O)
theinformationprovidedbythetreasury,throughtheirVLCsystem.
11 AG(O)willdoanagewiseanalysisofthesuspenseaccountandwill
generateabroadsheetwithopeningandclosingbalancealongwith AG(O)
theirtransactionfromVLCsystem.
12 Apartfromkeepingtrack,AG(O)willalsofollowupwiththeDDO
through a system generated letter, to clear the suspense account AG(O)
withinpredefinedtime.
SL. FUNCTIONALITY
1 Existing application should be changed to generate bill against the challan

automaticallythroughascheduler.
2 ExistingapplicationshouldbecustomisedtogeneratecentraladvicethroughCePC.
3 Application should be capable to generate automatic challan based on the failure

transactionavailableinRBIdebitscroll.
4 ExistingapplicationshouldbecapabletocommunicatetherespectiveDDOaboutthe
failuretransactionavailableintheRBIscroll
5 Existing application should be capable to allow the DDO to make changes to the
beneficiary details for the failure transaction till the bill again submitted by the
scheduler.
Page|93

6 ExistingapplicationshouldbecapabletosharedatawithAG(O)inordertomaintain
theagewisesuspenseinformation.
8.6.26. AccountCorrectioniniOTMS
TreasurysendstheiraccounttoAG(O)online.Subtreasuriesaccountsareconsolidatedatdistrict
treasurylevel.Thepaymentaccounthasbeensendtwiceamonth,firstandsecondlistandreceipt
account send once in a month. The second list of payment and receipt account can only be
downloadedbyAG(O)aftertheparticulartreasuryclosedtheaccountsuccessfully.
Butthereisapossibilitythattreasurycanmodifythetransaction,ifrequired,aftersendingthe
accounttoAG(O).TheexistingiOTMSapplicationneedstobechangedaccordinglyinorderto
incorporatesuchfacilities.
Sl. STEP ACTOR
1 Correction(addition/modification/deletion)madebytreasuryafter
thefirstlist,willbeintimatedtoAG(O)separatelywiththesecond Treasury
listofaccount.
2 After closing of the monthly account by treasury, AG(O) will Treasury&

downloadthesecondlistofpaymentalongwiththereceipt. AG(O)
3 Afterclosingofthemonthlyaccounttreasurymayrequiretodelete
ormodifyanypaymentorreceiptrelatedtransaction.Inthatcase
Treasury
treasurywillsendarequisitiononlinetoAG(O),requestingtoopen
themonthaccountfornecessaryrectification.
4 On received of such a requisition AG (O) will open the particular

month for that particular treasury to make the necessary AG(O)
modification.
5 Treasury will make such modification through transfer entry only.

Treasury
Originaltransactionsendpreviouslyshouldnotbechanged.Incase
of deletion of any payment or receipt related transaction cash
balance of that particular treasury should be changed accordingly

throughtransferentry.
6 After making the required changes treasury will close the month,
and all the transfer entry required to made the necessary Treasury
modificationwillbesendtoAG(O)
ChangesneededinAGVLCsoftware
7 AG (O) will download the necessary rectification entry and will Treasury
importthesameinVLC database,inordertoeffectthenecessary
Page|94

Sl. STEP ACTOR
changesmadebythetreasury.
SL. FUNCTIONALITY
1. Existing iOTMS application should be capable enough to identify the changed

transaction, made by treasury, after sending the first list in order to send those
separatelytoAG(O).
2. ExistingiOTMSapplicationshouldbecapabletomakeonlinerequisitiontoAG(O)for
openingthemonthaccountinordertomakenecessarytransferentry.
3. Existing iOTMS application should be capable to make necessary transfer entry to

rectifythetransactionsmade,withoutchangingthedataoforiginaltransactions.
4. ExistingiOTMSapplicationshouldbecapableenoughtogenerateaseparatefileofthe
transferentrymadeandmakeitavailabletoAG(O)
5. AGVLC software should be capable to import the modified transaction in order to

makethenecessaryeffectoftherectificationmadeattreasuryend.
6. Existing iOTMS application should be changed accordingly to give an interface to AG

(O)inordertoopenthemonthaccountbasedontherequisitionmadebytreasury.
8.6.27. COwiseOnlineReconciliation
Treasury submitsmonthly accounts to AGalongwiththe voucher details.AG (O) afterclosingof
the monthly accounts, publish a CO wise expenditure details that will be reconciled by the
respective CO, and required modification will be made at AG(O) side. Existing iOTMS application
needstobecustomizedinordertoavailthiskindoffacility.
Sl. STEP ACTOR

1 After closing the monthly accounts AG (O) will publish CO wise
expenditure details along with Head of Account (HoA) and TV AG(O)
number.
2 AG(O)willalsopublishthetransactionoccurredoutsidetheambit
AG(O)
oftreasury.
3 COwillthencheckthepublishedexpendituredata,andwillnotify
any modification required. CO will make an online request to AG CO
(O)forthiskindofmodification.
4 OnreceivingavalidrequestAG(O)makenecessarychangesandthe AG(O)
Page|95

Sl. STEP ACTOR
accountswillbechangedaccordingly
SL. FUNCTIONALITY
1 System should be capable to provide an interface to AG (O) to publish the CO wise
expenditure.
2 SystemshouldbecapabletogiveafacilitytoCO,tomakeanonlinerequesttoAG(O),
mentioningthevouchernumberandnecessarymodificationdetails.
3 System should be capable AG (O) to see the online request, and make necessary
approvaloftherectification.
8.6.28. BudgetDistributionAdvancefromOCFModuleIntegration
Usingthisfunctionalityfinancedepartmentcangiveadvancestoconcerndepartmentsandidentify
the advances to be recouped in the next supplementary budget. After the finance department
enter the advances details in the system the concerned department can get the advances as an
allotment for further distribution. During supplementary budget upload, system will identify the
advances taken by the user departments and the same will be recouped from the user
departments supplementary budget. The existing iOTMS application needs to be customized in
ordertoincorporatesuchoffacility.
Sl. STEP ACTOR

1 ThefinancedepartmentwillmaintaintheContingencyFundinthe
FD
system.
2 Finance Department will issue sanction order for any advances
FD
required,basedonwhichadvancewillbemade.
3 Apart from other necessary information, sanction order should
containavalidHeadofAccount(HoA)availablesystem.IftheHead
FD
of Account (HoA) is a new one then that must be created in the
systembeforeissuingthesanctionorder.
4 The budget section of the finance department will enter the

advance details with proper Head of Account (HoA) as per the BudgetSection
availablebalanceinthecontingencyfund.
5 The budget section will mention the recovery details like, from
whichyearsbudgetitwillberecovered,inthesystem.Generallyit BudgetSection
shouldbefromthecurrentyearssupplementarybudget.
6 TheBudgetOfficerverifiestheadvancedetailsagainstthesanction
order and made necessary modification if required and finally BudgetOfficer
approvestheadvance.
Page|96

Sl. STEP ACTOR
7 Theuserdepartmentgetstheadvanceasanallotmentintheirlogin
Department
forfurtherdistribution.
8 During supplementary budget upload, system will identify the

advances taken by the user departments to be recouped and the
System
samewillberecoupingfromthesupplementarybudgetoftheuser
departments.
SL. FUNCTIONALITY
1 System shall be workflow based. No one can modify any details if it is passed from
theirlevel.
2 Systemwillfacilitatetheupperleveluserstodrilldowntheentireprocess.
3 System shall facilitate the user to enterthemasterdetailtogive theadvancetothe
userdepartments.
4 System shall facilitate the users to identify the advances taken by the user
departmentstoberecoupedduringsupplementarybudget.
5 System shall be capable to validate the available balance in the contingency fund
duringadvanceprocessing.
6 Systemshouldfacilitateusertopreparetheadvanceandrecoupdetails.
8.6.29. BifurcationofStateshareandCentralsharefromCSP
Using this functionality the finance department will mention the % of state and central share in
centrallysponsoredplanbudget.Aftermentioningthepercentagebythefinancedepartment,the
systemwillbeabletogeneratetheactualbudgetandexpenditureasperthepercentagedefined
bythefinancedepartment.FurtherdepartmentandCOshouldbeabletomentionthe%ofshares
duringdistributionprocess,soitcanbetaggedwiththeexpenditureprocess.
Sl. STEP ACTOR
1 The finance department will mention the % of state share and

FD
centralshareincentrallysponsorplan
2 Thedepartmentuserwillentertheratioofstateshareandcentral
Department
share during distribution to CO level in case of centrally sponsor
user
plan.
3 The CO user will enter the ratio of state share and central share
COuser
duringdistributionprocessincaseofcentrallysponsorplan.
Page|97

SL. FUNCTIONALITY
2 System shall facilitate the user to enter the % of state share and central share in
centrallysponsorplan.
3 System shall facilitate the users to mention the ratio of shares during distribution
process.
4 System should be capable to validate that the ratio mentioned at the time of
distributionprocessshouldnotexceedthetotalamountmentionedfordifferentshare
bythefinancedepartment.
8.6.30. IntegrationwithWorksforestaccounts&WAMIS
Using this functionality the user can get the division wise allotment detail, division wise deposit
details,divisionwisedeductiondetailsanddivisionwisechequedetails.Systemiscapableenough
togeneratealltheserequiredfilesonrequestbasis.Systemshouldbecapableenoughtoidentify
thenewandmodifiedrowstosend.Duringchequeissue,systemshouldallowtheusertoselect
the vouchers against which the cheque was issued and populate all the voucher details in the
chequeissuescreen.
Sl. STEP ACTOR
1 WAMIS system will send request to existing iOTMS application

throughawebserviceforthefollowing
divisionwiseallotmentdetails
divisionwisedepositdetails Application
divisionwisedeductiondetails Automatic
divisionwisechequedetails
iOTMSsystemwillprocesstherequestandwillsendthenecessary
datainXMLformatthroughwebservice.
2 The system will allow the divisional officers to select vouchers

details entered in the system during cheque processing and
Divisionaluser
populate all the related information of the voucher in the cheque
issuescreen.
3 Afterpopulatingallthevoucherdetailsinthechequeissuescreen Divisionaluser
Page|98

Sl. STEP ACTOR
systemwillallowthedivisionalusertoissueacheque.
SL. FUNCTIONALITY
2 System should be capable to consume the request and provide necessary information
mentionedabove.
3 System should be capable to facilitate users to choose a voucher during cheque

processing.Alltherelatedinformationofthatparticularvoucherneedstobeavailable.
4 Systemiscapableenoughtogeneratechequewisevoucherdetails.
8.6.31. iOTMSCPSMSPortalIntegration
Using this functionality the CPSMS portal can download the state budget, state expenditure and
month wise state release. System will generate planning commission wise state budget, state
expenditure and month wise state release file in a schedule basis and stores these files in ftp
server,fromwheretheCPSMSportalwilldownloadthesefiles.
Sl. STEP ACTOR
1 CPSMSshouldprovideallthecentralplanningcommissionscheme
CPCMS
codestoiOTMS.
2 iOTMS should provide a facility to capture all the central planning

iOTMS
commissionschemecodesprovidedbyCPSMS.
3 The finance department will map all the planning commission Finance
schemeswiththecorrespondingstatebudget. department
4 System should be capable enough to generate all the related

information on schedule basis and store these files in a particular
locationofaserver,CPSMSshoulddownloadthesefilesthroughftp
like:
iOTMS
Schemewisestatebudget
Schemewisestateexpenditure
Schemewisemonthlyrelease
Page|99

SL FUNCTIONALITY
1 System shall be an automated one. No one can modify any details once the file is
generated.
2 Systemshallcapableenoughtodownloadcentralplanningcommissionschemecodeand
importiniOTMS.
3 On a schedule basis system should automatically generate all these required files and
storesinaparticularpathoftheserver.
4 Systemshouldbecapableenoughtoallowtheusertodownloadthestatebudget,state
expenditureandmonthwisestatereleasefilesusingftp.
8.6.32. IntegrationwithHRMS
DDOpreparessalarybillsthroughHRMSsystemattheendofeverymonth.Afterbillpreparation,
DDO takes the hard copy print out of the bill and its supporting documents like different types
schedules and then submits the bill manually to treasury for bill processing through iOTMS. To
make the bill submission process online, a tightly coupled integration is required between two
independentsystemiOTMSandHRMS.
Sl. STEP ACTOR
1 DDO prepares salary bill through HRMS system. Different types of

DDO
schedulesarealsogeneratedthroughHRMS.
2 Afterpreparationofsalarybill,allbillrelatedinformation,including
all schedules like By transfer, NPS, GPF / TPF, Payee / Beneficiary
list with their bank account number and payment amount, MCA,
HBA,ComputerAdvanceetcwillbeconvertedintodigitallysigned HRMS
XML files and the same will be transmitted to central server of Application
iFMSOdisha through secure FTP from HRMS application. HRMS
sendsDDOwisebillinformationforallapplicabletreasuriesofthe
statetocentralserver.
3 AtiOTMSend,systemwillrunaschedulertoperiodicallycheckthe
availabilityofthenewfilescomingfromHRMS.
In case of any new file, system first validates the bill information iOTMS
usingdifferenttypesofvalidationrules. application/
CentralLocation
Ifeverythingfoundok,thenthesamewillbeimportedtotreasury
system. The treasury and DDO wise bill information, including all
theschedules,willbeavailabletocorrespondingtreasuryusersfor
Page|100

Sl. STEP ACTOR
processing of the bill. No need to enter the bill information

manually at treasury level. Everything will be populated from
centrallocationfromXMLfilessentbyHRMS.
IncaseoffailureiOTMSapplicationwillsendthereasonoffailure
toHRMS.
4 In case of failure, after getting the reason of failure from iOTMS,

DDO/HRMS
DDOrectifytheerrorthroughHRMSandresubmitsthebillonline.
5 Afterreceivingthebillattreasury,thereareusuallythreelevelsof
checkingofthebillareperformedbytreasuryusersbeforesending
thepaymentadviceofthebilltoRBIforpayment.
iOTMS
iOTMS application will send the information of each stage of application
processingof bill at treasurytoHRMSsystem. After accounting of
the bill at treasury, voucher number and date will also be
transmittedtoHRMS.
SL. FUNCTIONALITY
transmissionofdata.
2 SystemshouldbecapabletointegratewithHRMS.
3 iOTMSapplicationwillshareinformationlikeHeadofAccount(HoA),Bytransferhead,
DDOsavailablebalance,PRANinformationetcwithHRMSthroughWebservice.
4 Serversidedigitalsignaturemustbeapplied
5 BeforeimportingthesalarybillrelateddatafromXMLfiletotreasurydatabase,iOTMS
systemmustvalidatetherelevantinformation.Somebasicvalidationsare:
DDOwiseproperHeadofAccount(HoA)mustbegiven.
NPS schedule must be checked for the correctness of DDO registration

number,PRANnumber,NPScontributionamountetc.
TotalamountofBeneficiarylistmustbematchedwiththenetamountofthe
salarybill.
Bank IFSC code mentioned in the beneficiary list will be validated with the
bankmastermaintainediniOTMSsystem.
Pay component wise breakup amount must be matched with the gross
Page|101

SL. FUNCTIONALITY
amountofthebill.
GPF/TPFschedulemustbecheckedwiththeGPF/TPFmastermaintainedin
iOTMSsystemforthecorrectnessofGPF/TPFnumber.
6 iOTMS application must communicate the file import status immediately to HRMS
seamlessly. In case of success, bill receives acknowledgement number i.e. token
number (Financial year and treasury wise Unique), generated by iOTMS application,
andmustbecommunicatedtoHRMS.Incaseoffailure,propererrormessagesmust
betransmittedtoHRMS.
7 Information regarding each stage of the processing of the bill at treasury, including
vouchernumberanddate,willbecommunicatedtoHRMS.
8 Incaseoffailureduringfileimportstageorbillrejectionbytreasuryuser,onlinebill
resubmissionfacilitymustbeprovided.
9 IntegrationwithRBIisrequiredtoupdatethebankmastermaintainediniOTMS.
10 IntegrationwithAGandControllerofAccountsarerequiredtoupdatetheGPF/TPF
masteriniOTMSsystem.
11 Secure FTP, web services are required for data exchange among different stake
holders.
12 DDOshouldbeabletocheckthestatusoftheirbillatanypointoftimeeitherusing
iOTMSportalorHRMSapplication.
13 SystemshouldcapabletogeneratedifferenttypesofMISreports.
14 iFMSOdishashouldbecapableenoughtoreceivebillsonlineaswellasmanually.
8.6.33. TreasuryOnlinePaymentRequestbyOperatorModuleIntegration
Thisprocessinvolvestwomajoractivities:
OnlinecreationofanewPLoperator
OnlinepreparationandsubmissionofPLpayment
8.6.33.1. ProcessDescription:OnlineCreationofaNewPLOperator
ItwillbeaworkflowbasedprocessforcreationofnewPLoperator.
Sl. STEP ACTOR
1 TreasuryreceivesonlineapprovalfromAdministrativeDepartment Treasury
for creation of the new PL operator along with the necessary
Page|102

Sl. STEP ACTOR
information like HoA to be linked with the new operator,

designationoftheoperator,linkedtreasuryname,PLoperators
bankaccountnumber,IFScodeetc.
2 System generated acknowledgement will be sent to Admin Treasury

Department. Application
3 Treasury validates some of the information like HoA to be linked

Treasury
withthenewoperator,BankIFSCcodeetc
4 If everything found ok, Treasury generates unique ID for the new

operator.Andtags thisnew operatorwiththe prescribedHead of
Account.Thisnewoperatoriscreatedwithzerobalance. Treasury
Incaseofanydiscrepancy,treasurywillsend back the requestto
Admindepartmentfornecessarycorrection.
5 Treasury will communicate the new operator id to concerned

Treasury
agencieslikeAG,Admindepartment,Headofdepartment
8.6.33.2. ProcessDescription:OnlinePLPaymentRequest
ThisfunctionalitywillautomatethePLpaymentprocess.
Sl. STEP ACTOR
1 Treasury receipts payment request online from PL operator along

with the required information for payment. System generated
Treasury
acknowledgement will be sent to the PL operator for future
reference.
2 Treasury user first checks the details of the payment sent by PL

operator. Availability of funds is also checked by treasury. 3 level Treasury
checkingwillbedone.
3 If everything found ok, then the payment request is forwarded to

treasuryofficer(TO)forapproval.Systemwillautomaticallydeduct
thebalanceoftheoperator. Treasury
Incaseofanydiscrepancy,treasurywillrejectthepaymentrequest
andintimatetheoperatorfornecessarycorrection.
4 TO approves the request and sends digitally signed encrypted e

payment advice online to bank in NEFT/CBS/RTGS format for
Treasury
deposit of the claim amount to the beneficiarys bank account
number.
Page|103

Sl. STEP ACTOR
5 Onreceiptofepaymentscrollfrombank,treasurywillimportthe
Treasury
sameforaccounting.
6 PaymentinformationwillbecommunicatedtothePLoperator Treasury
SL. FUNCTIONALITY
1 Systemshouldbeaworkflowbasedsystem.
transaction
3 SystemshouldbecapabletointegratewithAG,LinkBankforaccountstransferandfor
paymentrespectively
4 System must validate the basic information of the entry like valid IFSC code, MICR
code,checkingofavailablebalanceetc
5 Thesystemshouldcapabletohandlethedigitalsignature,encryptionanddecryption
facility.
6 System shall facilitate the treasury to upload the eadvice to the link bank and to
downloadescrolluploadedbylinkbank.
7 Systemshallfacilitatethelinkbanktodownloadtheeadviceandtouploadescroll.
8 SystemshouldbecapabletogenerateSMS/emailnotificationtothebeneficiary/PL
operator.
9 DifferenttypesPLexpenditurerelatedreportsmustbegeneratedthroughthesystem
8.7. Deliverables
MajorDeliverablesoftheprojectincludebutarenotlimitedtothefollowing:
Detailedactivityplan.
DetailedUserRequirementSpecificationthatagreeduponbyFinanceDepartment.
Detailed Software Requirement Specification (SRS) document for all the functional
modulesofiFMSOdishasystem.
DetailedComputerisationActionPlanandfortnightlyprogressreportsagainsttheagreed
ActionPlan.
SupervisionofInstallationofServeranddaytodaymanagement.
DeploymentofApplicationSoftwareandoperationalizingatalldefinedlocations.
Designdocuments&SourceCodeforcompletesoftwaresolution.
SystemTestPlanandSystemTestResults(STR)undervariedconditions.
Page|104

Qualitycertificationofsoftware
UserManual,InstallationManual,OperationManual&MaintenanceManual,Computer
basedTutorial.Allmanualsalsoshouldbeavailableincontextsensitivehelpform.
HelpDeskToolandComplainManagementTool.
Knowledgetomaintainsoftwareanddatacentre.
Page|105

9. KeyPersonnel
Thebiddershavetofurnishresumesofkeypersonnelbothsupervisoryandtechnical.The
bidder must demonstratetheavailabilityand degree ofcommitment ofpersonnelwithtechnical
expertise.Resumesmustincludeeducation,experience,background,accomplishments,andother
pertinentinformation.Theresourcesforbelowmentionedcategoriesshouldbeontherollsofthe
companyasonthedateofsubmissionofbid.
Sl.
KeyPersonnel Eligibility
No.
S/he must have minimum education as B.E. (Computer
Science/ Electronics/ IT) or MCA and possess total 58
yearsofpostqualificationexperienceincludingatleast3
SystemAnalyst/Software yearsofrelevantexperienceinthefieldasmentionedin
Engineer/Maintenance& the left column. Consultants having any technical
SupportEngineer/System certification in addition to the educational qualification
1 Administrator/Database will be preferred. Experience of the consultant in large,
Administrator/DataCenter complex, turnkey projects is essential. Consultants
Manager exposure to eGovernance system in general,
Government Treasuries and Finance Management in
specific, is preferred. Consultants having proficiency in
locallanguagewillhaveaddedadvantage.

Science/ Electronics/ IT)/ MCA or a graduate preferably
from science stream with PGDCA from a recognized
university and possess minimum 3 years of post
2 HelpDeskResourcePerson qualificationexperienceinsoftwareimplementationand
training. Consultants exposure to eGovernance system
in general, Government Treasuries and Finance
Management in specific, is preferred. S/he must have
proficiencyinlocallanguage.
from science stream with PGDCA from a recognized
qualificationexperienceinsoftwareimplementationand
3 ImplementationEngineer training. Experience of the consultant in large, complex,
turnkeyprojectsisessential.Consultantsexposuretoe
Governance system in general, Government Treasuries
and Finance Management in specific, is preferred.
Consultantshavingproficiencyinlocallanguagewillhave
addedadvantage.
4 Trainer from science stream with PGDCA from a recognized
qualificationexperienceinsoftwareimplementationand
Page|106

Sl.
KeyPersonnel Eligibility
No.
training. Consultants exposure to eGovernance system
in general, Government Treasuries and Finance
Management in specific, is preferred. S/he must be
havingproficiencyinlocallanguage.
Page|107

10.ProjectTimelines
Government of Odisha plans to rollout iFMSOdisha services and functions in a phased
manner, where each phase is broken down into smaller steps to match the resources and
capacitiesatthedisposalofthegovernment.
10.1. ImplementationPhases
Trainingto
Tobe
New beprovided
Integrated Target Noof
modules and
Id Modules with officeof usersin
tobe Modulesto
existing stakeholder offices
developed be
system
implemented
PHASEI
1 BudgetPlanning& Yes Yes FD 50
Preparation P&C 10
DDO 13000
CO 350
AD 100
2 DebtManagement Yes Yes FD 20
System
3 PensionFinalization Yes Yes CoA 25
andpreparationof
PensionPayment
Order(PPO)
4 eDisbursementof Yes Treasury 500
governmentclaims DDO 13000
(Treasurydrawl)
5 eDisbursementof Yes Yes Yes Divisions 750
governmentclaims
(ChequeDrawl)
6 NPSmonitoring Yes Yes DTI 10
systemincludingESS
forthenew
employees
7 CentralizedNPS Yes Yes Yes DDO 13000
Contribution
Uploading
8 Financialdata Yes Yes FD 15
warehouseand DTI 10
BudgetDecision
SupportSystems
(BDSS)I
9 Online/OfflineBill Yes Yes Yes Treasury 500
Submission&
Page|108

Trainingto
Tobe
New beprovided
modules and
tobe Modulesto
developed be
system
implemented
IntegrationModule DDO 13000
10 VirtualTreasury Yes Yes
Module(Integration
withcybertreasury)
11 TreasuryBudget Yes
Preparation&DSS
ModuleIntegration
12 iOTMSPortalMobile Yes
BasedTaxPayment
Integration
13 AccountCorrectionin Yes Yes Treasury 350
iOTMS
14 SanctionOrder Yes Yes Yes FD 10
DatabaseModule DTI 5
developmentand Treasury 350
Integrationwith
Paymentmodule
15 BudgetDistribution Yes Yes FD 10

AdvancefromOCF DTI 5
ModuleIntegration
16 Bifurcationofstate Yes Yes FD 10

shareandcentral DTI 5
sharefromCSP
PHASEII
17 FundManagement Yes Yes FD 10
System

18 RBIIntegrationand Yes Yes FD 10
MonitoringofWays
andMeans
19 Works&ForestBill Yes Yes DDO 750
processingand (Cheque
Accountsgeneration Drawal)
20 Schemeof Yes Yes FD 10
Consolidatedfund DTI 5
expendituretracking
incurredoutside/
Page|109

Trainingto
Tobe
New beprovided
modules and
tobe Modulesto
developed be
system
implemented
inside
21 BudgetDecision Yes Yes FD 10
SupportSystems DTI 5
(BDSS)II
22 COwiseonline Yes Yes FD 10
reconciliation DTI 5
23 Accountscorrectionin Yes Yes Yes Treasury 100

iOTMS (district
&spl.)
AG
24 Integrationwith Yes Yes DDO 650
Worksforestaccounts (Cheque
&WAMIS Drawal,
except
Forest)
25 iOTMSCPSMSportal Yes Yes FD 10
Integration DTI 5
26 IntegrationwithHRMS Yes Yes Treasury 500

Office
PHASEIII
27 TeachersProvident Yes Yes CoA 25
Fund(TPF)
28 Monitoringand Yes Yes DTI 5
ControllingUtilization Treasury 300
Certificate(UC) DDO 6500
30 OnlinePayment Yes Yes PL 1100
requestfromPL operator
operator
31 OnlineAudit& Yes Yes DTI 10
Inspection
32 PaymentTPF Yes
Moduleintegration
33 TreasuryOnline Yes
Paymentrequestby
PLoperatorModule
Integration
34 Mobilebased Yes Yes
Page|110

Trainingto
Tobe
New beprovided
modules and
tobe Modulesto
developed be
system
implemented
Paymentand
Transactionreporting
system
10.2. ImplementationSchedule
Following is a tentative schedule as shown below. The final schedule will be worked out with
FinanceDepartmentafterthesigningoffofagreementinconsultationofPeMT.
Year1 Year2 Year3 Year4 Year5

TaskName
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 H1 H2 H1 H2
PhaseIModules
SystemRequirement

Study
ApplicationSoftware

Development
Training&

Implementation
PhaseIIModules
SystemRequirement

Study
ApplicationSW

Development
Training&

Implementation
PhaseIIIModules
SystemRequirement

Study
ApplicationSW

Development
Training&

Implementation
Maintenance&

SupportServices
HelpDeskOperation
SoftwareEnhancement (5000Mandays)
Page|111

10.3. GovernanceStrategy
Finance Department, Government of Odisha has taken necessary steps in accordance to
the guideline issued from Department of Information Technology, Government of India for
implementingthisMissionModeProject(MMP).
A. Empowered Committee is formed under chairmanship of the Principal Secretary, Finance
Departmenttoprovideoverallguidanceanddecidepolicylevelmatters,financialmatters
andtoactasfinalbodyforapprovingalldeliverablesrelatingtotheproject.
B. Project eMission Team (PeMT) will be formed to provide overall project leadership and
take full ownership of the project design, development including transformation, change
management, strategic control, and business process reengineering at the core level and
ongoingsupportandupgrades.ThePeMTisalsoresponsibleforimplementation,rollout,
operationsandmaintenance.
C. Process Advisory Committee (PAC) & State Technical Committee will be created under
PeMT to provide technology support during project period. There will be a designated
Mission Leader and Project Leader responsible for life cycle management of the Mission
ModelProject.
Page|112

11. ServiceLevelAgreement
11.1. CompensationforTerminationofContract
If the bidder fails to carry out the award / work order in terms of this document within the
stipulatedperiodoranyextensionthereof,asmaybeallowedbyFinanceDepartment,withoutany
validreasonsacceptabletoFinanceDepartment,FinanceDepartmentmayterminatethecontract
aftergivingonemonthnotice,andthedecisionofFinanceDepartmentonthemattershallbefinal
and binding on the bidder. Upon termination of the contract, Finance Department shall be at
libertytogettheworkdoneattheriskandexpenseofthebidderthroughanyotheragency,andto
recoverfromthebiddercompensationordamages.
11.2. LiquidatedDamages
Intheeventofdelayinexecutionofwork,specifiedinthisContract/furnishingofdeliverables,
the bidder shall be liable to a penalty @1% of the value of work order in respective phases, for
everymonthofdelayuptoamaximumof10%,afterwhichFinanceDepartmentshallbeatliberty
tocanceltheaward.Forthepurposeofthisclause,partofaweekshallbeconsideredtobeafull
week.
11.3. QualityoftheSoftware
Finance Department will engage a third party quality certification agency for quality
certificationofthesoftwareapplication.Itistheresponsibilityoftheserviceprovidertomakethe
applicationsoftwarecertifiedbythequalitycertificationagencyselectedbyFinanceDepartment.
The Service Provider should complete the quality certification process either within 30 months
afterissueofworkorderorwithin6monthsaftercompletionofthirdphasedelivery.
11.4. SystemUptime&Performance
The service provider will ensure that Average Network Availability between various defined
operating locations is not less than minimum 95% always except in any Planned Network Outage
approved by PeMT in advance. The service provider will ensure that average page loading time for
application & reports is not more than 30 seconds. The service level dependency in this case is
functioning of Telephone Exchange Line, uncovered power outage by the State Data Center,
breakdownofthehardwareandnetworkingequipmentoftheservers.
11.5. Training
Quality and Effectiveness of the training sessions conducted by service provider for staff
members&stakeholdersaretobeverifiedbyanythirdpartytechnicaluniversityengagedbythe
Finance Department. The third party technical university will conduct a survey, collect feedbacks
fromtheparticipantsandsubmitareportonqualityandeffectivenessofthetrainingprovidedby
theserviceprovider.
11.6. HelpdeskSupport
Except for the month of March, helpdesk will provide its services on all working days of
Government ofOdisha between 10:00 AMto6.00PM.InthemonthofMarchof every year the
helpdeskshouldbeoperationalfrom8AMto8PM,sevendaysaweek,includingSundays,while
Page|113

onthelastworkingdayofMarchitshouldbeoperationalfrom8AMto12AMofmidnight.The
serviceprovidershouldadheretotheseveritylevelsandminimumresponsetimeofdifferenttype
ofcallsasproposedbyPeMT.Theserviceprovidermustresolveatleast90%ofloggedcomplains
within7daysofregistration.
11.7. Pilottestingandrollout
Theserviceprovidermustdeviseacceptancecriteriaforcompletionofrolloutinconsultation
withthePeMT.Theacceptancecriteriashouldbemodulespecific.Theserviceproviderissupposed
to meet such criteria as successful completion of rollout of specific module in each target user
office.
Page|114

12. AcceptanceTestingandCertification
Serviceprovidershallprovidetechnicalassistancetomaketheapplicationsoftwarecertifiedbyany
reputedqualitycertificationagencyselectedbyFinanceDepartment.TheprimarygoalofAcceptance
Testing and Certification is to ensure that the Project (including all the project components as
discussedinthescopeofwork)meetsrequirements,standards,specificationsandperformance,by
ensuringthatthefollowingareassociatedwithclear,quantifiablemetricsforaccountability:
Functionalrequirements
AvailabilityoftheprojectServicesinthedefinedlocations
Performance
Security
Manageability
SLAReportingSystem
ProjectDocumentation(Design,development,configuration,trainingandadministration
manualsetc)
DataQualityReview
As part of Acceptance testing, performed through a third party agency, Finance Department shall
reviewallaspectsofprojectdevelopmentandimplementationcoveringsoftwaredevelopmentand
implementation,includingtheprocessesrelatingto:
the design of solution architecture, design of other related/required applications, coding,
testing,businessprocessdescription,documentation,versioncontrol,changemanagement,
security,serviceorientedarchitecture
Interoperability,scalability,availability,performancewithrespecttodefinedrequirements,
andcompliancewithallthetechnicalandfunctionalrequirementsoftheRFPandthe
agreement.
TheproceduresandparametersfortestingwillbelaiddownbytheThirdPartyAgencyafterapproval
fromFinanceDepartment;thesolutiondeployedbythevendorhastosatisfythirdpartyacceptance
testinguponwhichthesystemshallgolive,subjecttoFinanceDepartmentsapproval.
TheFinanceDepartmentwillestablishappropriateprocessesfornotifyingtheselectedvendorofany
shortcomings from defined requirements at the earliest instance after noticing the same to enable
the selected vendor to take corrective action. All gaps identified shall be addressed by the vendor
immediatelypriortoGoliveofthesolution.ItistheresponsibilityoftheselectedBiddertotakeany
correctiveactionrequiredtoremoveallshortcomings,beforetherolloutoftheproject.
Itistobenotedthattheinvolvementofthethirdpartyforacceptancetestingandcertification,does
notabsolvethevendorofhisresponsibilitiestomeetallSLAsaslaidoutinthisRFPdocument.
Itistobenotedthat,FinanceDepartmentmaygetthesolutionauditedthroughaThirdPartybefore
GoLiveandperiodicallyafterGoLiveinordertoensurethesuccessoftheproject.Suchthirdparty
agency for carrying out the acceptance testing and certification of the entire solution will be
nominated by the Department. Following discusses the acceptance criteria to be adopted for the
project as mentioned above. The list below is indicative and the activities will include but not be
limitedtothefollowing:
Page|115

12.1. FunctionalRequirementsReview
Thesolutiondeveloped/customizedbyselectedBiddershallbereviewedandverifiedbytheagency
against the Functional Requirements signedoff between the <Nodal Agency> and the selected
Bidder. All gaps, identified shall be addressed by the vendor immediately prior to Golive of the
solution.Oneofthekeyinputsforthistestingshallbethetraceabilitymatrixtobedevelopedbythe
vendorforthesolution.ApartfromTraceabilityMatrix,agencymaydevelopitsowntestingplansfor
validationof complianceof system against the definedrequirements. The acceptance testing w.r.t.
thefunctionalrequirementsshallbeperformedbyindependentthirdpartyagency(externalaudit)as
wellastheselectinternaldepartmentusers(UserAcceptanceTesting)andsystemhastosatisfyboth
thirdpartyacceptancetestingandinternaluseracceptancetesting,uponwhichthesystemshallgo
live.
For conducting the User Acceptance Testing, <Nodal Agency>/ The Department shall identify the
employees from respective divisions, who shall be responsible for daytoday operations of the
functions automated through the project. The system, during the functional requirements review,
shallnecessarilysatisfytheuseracceptancetestingprocess.
12.2. SecurityReview
The software developed/customized shall be audited by the agency from a security and controls
perspective. Such audit may also include the IT infrastructure deployed in connection with the
softwarefortheproject.FollowingarethebroadactivitiestobeperformedbytheAgencyaspartof
SecurityReview.Thesecurityreviewshallsubjectthesolutiontoatleastthefollowingactivities.
Assessmentofauthenticationmechanismprovidedintheapplication/components/modules
Assessmentofdataencryptionmechanismsimplementedforthesolution
Assessmentofdataaccessprivileges,retentionperiodsandarchivalmechanisms
ServerandApplicationsecurityfeaturesincorporatedetc
12.3. Performance
Performanceisanotherkeyrequirementfortheprojectandtheagencyshallreviewtheperformance
of the deployed solution against certain key parameters defined in SLA. Such parameters include
requestresponsetime,workflowprocessingtime,concurrentsessionssupportedbythesystemetc,
Disaster Recovery drill etc. The performance review also includes verification of scalability
provisionedinthesolutionforcateringtotheprojectrequirements.
12.4. SLAReportingSystem
The selected Bidder shall design, implement/customize the Enterprise Management System (EMS)
andshalldevelopanyadditionaltoolsrequiredtomonitortheperformanceindicatorslistedasper
the SLAs mentioned the RFP. The Acceptance Testing and Certification agency shall verify the
accuracyandcompletenessoftheinformationcapturedbytheSLAmonitoringsystemimplemented
bythevendorandshallcertifythesame.TheEMSdeployedfortheproject,basedonSLAs,shallbe
configured by the selected Bidder to calculate the payment to be paid by the department after
deductingthenecessarypenalties.
Page|116

12.5. ProjectDocumentation
The Agency shall review the project documents developed by the selected Bidder including
requirements,design,sourcecode,installation,trainingandadministrationmanuals,versioncontrol
etc.Anyissues/gaps identifiedbytheAgency,in anyofthe aboveareas,shallbe addressedtothe
completesatisfactionoftheDepartment.
12.6. DataQuality
TheAgencyshallperformtheDataQualityAssessmentfortheDatadigitizedbyselectedBidderand
the data migrated by the vendor to the new system. The errors/gaps identified during the Data
Quality Assessment shall be addressed by the vendor before moving the data into production
environment,whichisakeymilestoneforGoliveofthesolution.
Page|117

13. PaymentSchedules
Payment will be made as per the schedule given below subject to acceptance certificates of
respective service. Thebidder should quoteprice in Indian Rupeesonly. The offered pricemust be
exclusiveoftaxesandduties.Thetaxesasappropriate&applicablewouldbepaidattheprevalent
rates.
Deliverable PaymentAmount
UserRequirementSpecification,SystemRequirement 20%ofcostofsoftwaredevelopment
Specification aspernumberofmodulescovered
SubmissionofSourceCodeforSoftwareModules
SystemTestResults(STR)ofSoftwareModules
40%ofcostofsoftwaredevelopment
UserManuals,OperationManuals&TrainingMaterialsfor aspernumberofmodulescovered
SoftwareModules
Completionreportonpilotimplementation
Reportoncompletionoftrainingtousersofeachtarget 30%ofcostofsoftwaredevelopment
officesonSoftwareModules aspernumberofmodulescovered
100%ofcostoftrainingasper
Certificationofthirdpartytechnicaluniversityonsuccessful numberofmodulescovered
completionoftrainingonSoftwareModules
100%ofcostofPilotTesting&Rollout
ReportoncompletionofRolloutofSoftwareModulesat
aspernumberofmodulewisetarget
eachtargetuseroffices
officescovered
Costofmaintenanceandsupportas
Monthlyreportofmaintenance&supportservice peractualconsumptionofserviceon
quarterlybasis
CostofHelpdeskoperationasper
MonthlyreportofHelpdeskOperationservice actualconsumptionofserviceon
quarterlybasis
10%ofcostofsoftwaredevelopment
QualityAssurancecertificationfromthirdpartyQAagency
aspernumberofmodulescertified
Page|118

14. AcceptanceCriterion
Finance Department (FD) will formulate a project management unit (PeMT) for successful
implementation ofthe proposed system. Resource personsof theservice provider willclosely work
withPeMTduringsystemstudy,softwaredevelopment,implementationandsupportphase.Different
deliverablesprovidedbytheserviceproviderindifferentstagewillbeverifiedbythePeMT.Athird
party agency will be engaged for Quality Audit and Security Certification of the proposed Project.
PeMT along with the selected Quality Certifying Agency will ensure the quality of each deliverables
provided by the Service Provider. Every deliverable will be accepted only after due approval by the
responsibleapprover(PeMT/QCA/ThirdPartyUniversity).
AnactivityplanwillbesubmittedbytheServiceProviderasfirstdeliverableoftheproject.PeMTwill
verifythesameandgetitapprovedfromtheFinanceDepartmenttostartthenextactivities.
ServiceproviderwillpreparethedetailedUserRequirementSpecification(ToBeProcess)document
andwillgetitapprovedbyProjecteMissionTeam(PeMT)ofFinanceDepartment.
Service provider will prepare the System Requirement Specification (SRS) document based on the
functionalitiessuggestedinthisdocument.SRSdocumentwillbeapprovedbytheProjecteMission
Team(PeMT)ofFinanceDepartment.
The selected service provider will design and develop the software modules of the system as per
agreed priority list.Prepare documentation relating to software design & development process.
Conductthoroughtestingtoensureflawlessreleaseofthesoftware.
TheQualityCertifyingAgency(QCA)willcheckallthedeliverablesindesignanddevelopmentphase.
Deliverablesinthisphasearea)completesourcecodeofthesoftware,b)Technicaldocumentation
relatedtodesignanddevelopment,c)SystemTestResults.
UserManuals,InstallationManuals,OperationManuals&MaintenanceManuals&TrainingMaterials
will be provided by the service provider. Standard of these deliveries will be checked by the QCA.
PeMTofFinanceDepartmentwillensurethecorrectnessofcontentofthesedeliverables.
It is the responsibility of the service provider to provide required training to the end user. After
completion of such training program Finance Department will engage a third party university for
verificationandcertificationofqualityoftrainingimpartedbytheserviceprovider.Paymentwillbe
madetotheserviceprovideraftergettingfeedbackfromthethirdpartyuniversity.
Alistofdeliverablesalongwithapproverisgivenbelow:
Sl Deliverable Approver
1 ActivityPlan PeMT
2 UserRequirementSpecification PeMT
3 SystemRequirementSpecification PeMT
5 SourceCodeforcompletesoftwaresolution ThirdPartyQC
Agency
6 SystemTestResults(STR) ThirdPartyQC
Agency
7 UserManuals,InstallationManuals,OperationManuals&MaintenanceManuals ThirdPartyQC
&TrainingMaterials Agency
Page|119

Sl Deliverable Approver
8 Training&Handholding Third Party

University
9 SuccessfulImplementation Department
10 DataCentreManagement Department
11 SoftwareMaintenance&MISService Department
12 ProjectClosure Department
Page|120

15. FraudandCorruptPractices
FinanceDepartmentrequiresthattheTenderersunderthistenderobservethehigheststandardsof
ethics during the procurement and execution of such contracts. In pursuance of this policy, the
Purchaser(i.e.FinanceDepartment)definesthetermssetforthasfollows:
A. Corrupt Practice means the offering, giving, receiving or soliciting of anything of
value to influence theaction ofthe public official in theprocurement process or in
contractexecution;and
B. Fraudulent Practice means a misrepresentation of facts, in order to influence a
procurement process or execution of a contracttothe detriment of the Purchaser,
and includes collusive practice among Bidders (prior to or after bid submission),
designedtoestablishbidpricesatartificialnoncompetitivelevelsandtodeprivethe
Purchaserofthebenefitsofthefreeandopencompetition;
C. The Purchaser will reject a proposal for award if it determines that the Bidder
recommendedforawardhasengagedincorruptorfraudulentpracticesincompeting
forthecontractinquestion.
D. ThePurchaserwilldeclareaBidderineligible,eitherindefinitelyorforastatedperiod
oftime,tobeawardedacontractifatanytimeitisdeterminedthattheBidderhas
engagedincorruptandfraudulentpracticesincompetingfororinexecutionofthe
contract.
Page|121

AppendixI:PreQualificationTemplates
Form1:ComplianceSheetforPreQualificationProposal
RFPNO:______________,Date:_______________
Please check whether following have been enclosed in the respective covers, namely, letter of
GeneralBid(PrequalificationCriteria).
a. CertificateofIncorporationandCertificateofCommencementissuedby Yes/No
theRegistrarofCompanies
b. Audited Balance Sheet and Annual Reports of the last three financial Yes/No
yearsuptoMarch31,2012
c. Undertakingonthenumberofpersonnelunderpayrollhavingminimum
Yes/No
qualification of B.E/ MCA and having atleast 2 years of experience in
softwaredevelopmentandimplementationasonMarch31,2012
d. Project Contract Document / Agreement and Satisfactory Completion Yes/No
Certificatebytheclient
e. UptodateVATClearencecertificatetillMarch31,2012 Yes/No
f. SEICMMiLevel5,ISO9001,ISO27001Certificatehavingvaliditytillthe
Yes/No
dateofpublicationofthisRFPorbeyond
g. Proof of owning the IPR & Source Code of the solution/ product/ Yes/No
solutionframeworkbeingofferedunderthisRFP
h. Self declaration of not be under ineligibility for corrupt and fraudulent
Yes/No
practicesissuedbyGovt.ofIndia/StateGovt.andnothaveanyrecord
ofpoorperformance,abandonedwork,havingbeenblacklistedbyany
state government or government of India, having inordinately delayed
completionandhavingfacedCommercialfailures
i. Tender Paper Cost (DD No.: .., Amount: , Bank:
Yes/No
..,Date:..)
j. Earnest Money (DD/BG No.: .., Amount: ., Bank.: Yes/No
..,Date:...)(AppendixI,Form3)
k. Acceptanceofterms&conditionscontainedinthetenderdocuments Yes/No
l. CopyofPowerofAttorneyinthenameoftheAuthorizedsignatory
Yes/No
m. ParticularsoftheBidder
Yes/No
(IntheformatattachedatAppendixI,Form2)

Signatureofwitness SignatureoftheTenderer
Date: Date:
Place: Place:
CompanySeal
Page|122

Form2:ParticularsoftheBidder
RFPNO:______________,Date:_______________
1. NameoftheFirm/Company
2. IncorporationStatus
3. AddressofOffice
4. TelephoneNo FaxNo
5. EmailAddress
6. Website
7. RegistrationNo&Date
8. NoofFulltimepersonnel:
S/WDevelopment Operations Other Total

9. No.ofyearsofprovenexperienceofprovidingsimilarServicesinOrissa:
10. AnnualTurnoverofthecompany(inlastthreeyears)
Amount(Rs.)
FiscalYear
PBT PAT ATO
20092010
20102011
20112012
11. Certification
TypeofCertification ValidFrom ValidTillDate

SEICMMiLevel5
ISOIEC9001
ISOIEC27001
AnyOther(Pleasespecify______________________)
12. TotalValueoftheCompany(inRupees):
Date: Date:
Place: Place:
CompanySeal
Page|123

Form3:BankGuaranteeforEarnestMoneyDeposit
RFPNO:______________,Date:_______________
To,
Bhubaneswar
Phone:06742390725
Fax:06742531142
EMail:dticentrallocation@gmail.com
Whereas <<Name of the bidder>> (hereinafter called 'the Bidder') has submitted the bid for
SubmissionofRFP#<<RFPNumber>>dated<<Date>>forDesign,Develop,Implement&Supportof
Integrated Finance Management System, Odisha (iFMSOdisha) (hereinafter called "the Bid") to
DirectorofTreasuries&Inspection.
KnowallMenbythesepresentsthatwe<<NameoftheBidder>>havingourofficeat<<Address>>
(hereinafter called "the Bank") are bound unto the <<Nodal Agency>> (hereinafter called "the
Purchaser")inthesumofRs.<<Amountinfigures>>(Rupees<<Amountinwords>>only)forwhich
payment well and truly to be made to the said Purchaser, the Bank binds itself, its successors and
assignsbythesepresents.SealedwiththeCommonSealofthesaidBankthis<<Date>>
Theconditionsofthisobligationare:
1. IftheBidderhavingitsbidwithdrawnduringtheperiodofbidvalidityspecifiedbytheBidderon
theBidForm;or
2. IftheBidder,havingbeennotifiedoftheacceptanceofitsbidbythePurchaserduringtheperiod
ofvalidityofbid
(a) Withdrawshisparticipationfromthebidduringtheperiodofvalidityofbiddocument;or
(b) FailsorrefusestoparticipateinthesubsequentTenderprocessafterhavingbeenshort
listed;
We undertake to pay to the Purchaser up to the above amount upon receipt of its first written
demand,withoutthePurchaserhavingtosubstantiateitsdemand,providedthatinitsdemandthe
Purchaserwillnotethattheamountclaimedbyitisduetoitowingtotheoccurrenceofoneorboth
ofthetwoconditions,specifyingtheoccurredconditionorconditions.
Thisguaranteewillremaininforceupto<<insertdate>>andincluding<<extratimeoverandabove
mandatedintheRFP>>fromthelastdateofsubmissionandanydemandinrespectthereofshould
reachtheBanknotlaterthantheabovedate.
Page|124

NOTHWITHSTANDINGANYTHINGCONTAINEDHEREIN:
I. OurliabilityunderthisBankGuaranteeshallnotexceedRs.<<Amountinfigures>>(Rupees
<<Amountinwords>>only)
II. ThisBankGuaranteeshallbevalidupto<<insertdate>>)
III. It is condition of our liability for payment of the guaranteed amount or any part thereof
arising under this Bank Guarantee that we receive a valid written claim or demand for
paymentunderthisBankGuaranteeonorbefore<<insertdate>>)failingwhichourliability
undertheguaranteewillautomaticallycease.

(AuthorizedSignatoryoftheBank)
Seal:
Date:
Page|125


AppendixII:TechnicalProposal
Form4:ComplianceSheetforTechnicalProposal
RFPNO:______________,Date:_______________
Pleasecheckwhetherfollowinghavebeenenclosedintherespectivecovers,namely,TechnicalBid.

I. BidLetter(Technical) Yes/No
(IntheformatattachedatAppendixII,Form5)
II. ListofProjectsExecutedinLast3years Yes/No
III. ProjectCitationFormat Yes/No
IV. ProposedSolution Yes/No
V. PrposedWorkplan Yes/No
VI. TeamComposition Yes/No
VII. FormatofCVforproposedtechnicalstaffofbidder Yes/No
VIII. DeploymentofPersonnel Yes/No

Date: Date:
Place: Place:
CompanySeal
Page|126

Form5:BidLetter(TechnicalBid)
RFPNO:______________,Date:_______________
<Location,Date>
To
Bhubaneswar
Treasury&AccountsBhawan,
UnitIII,KharavelNagar,Bhubaneswar
Phone:06742390725
Fax:06742531142
Subject: SubmissionoftheTechnicalbidforDesign,Develop,Implement&SupportofIntegrated
FinanceManagementSystem,Odisha(iFMSOdisha).
DearSir/Madam,
We, the undersigned, offer to provide Systems Implementation solutions to the Director of
TreasuriesandInspection,Odisha,BhubaneswaronIntegratedFinanceManagementSystem,Odisha
(iFMSOdisha)withyourRequestforProposaldated<insertdate>andourProposal.Wearehereby
submittingourProposal,whichincludesthisTechnicalbidandtheFinancialBidsealedinaseparate
envelope.
WeherebydeclarethatalltheinformationandstatementsmadeinthisTechnicalbidaretrueand
acceptthatanymisinterpretationcontainedinitmayleadtoourdisqualification.
Weundertake,ifourProposalisaccepted,toinitiatetheImplementationservicesrelatedtothe
assignmentnotlaterthanthedateindicatedinFactSheet.
WeagreetoabidebyallthetermsandconditionsoftheRFPdocument.Wewouldholdthetermsof
ourbidvalidfor180daysasstipulatedintheRFPdocument.
WeunderstandyouarenotboundtoacceptanyProposalyoureceive.
Yourssincerely,
AuthorizedSignature[Infullandinitials]:
NameandTitleofSignatory:
NameofFirm:
Address:
Location: Date:
Page|127

Form6:FormatforListofProjectsExecutedinLast3Years
RFPNO:______________,Date:_______________
Project IsthisProject Isthisane

Period Software Relatedto Governance
Name, Nameof Development, Total Treasury/ Project
Sl Addressof the Implementation Project Finance executedin
theClient Project andSupport Cost Management India
From To
Cost
(Yes/No) (Yes/No)
(1) (2) (3) (4) (5) (6) (7) (8) (9)
Note: Theinformationprovidedintheabovetablemustsupportedbyrelevantworkordercopy.Incasecost
of software development, implementation and support is not exclusively mentioned (Col.6 of above
table)thanitwillbetakenequivalentofofthetotalprojectcost(Col.7ofabovetable).
Date: Date:
Place: Place:
CompanySeal
Page|128

Form7:ProjectCitationFormat
RFPNO:______________,Date:_______________
I. ClientDetails
1. NameoftheClient :
2. SectoroftheClient(PutatickMark):a.Govt.inIndia b.ForeignGovt.
c.PSUinIndia d.Others
3. ClientReference(Name,Designation,PostalAddress,Phone,Fax,email):

II. ProjectDetail
4. NameoftheProject:
5. WorkOrderNo&Date
6. ProjectStartDate: CompletionDate
7. ProjectCost(ExcludingTaxinINR):
SoftwareDevelopment, Hardware,SoftwareLicense,
TotalProjectCost
ImplementationandSupportCost Installation&MaintenanceCost
Rs. Rs. Rs.
8. No.ofskilledITProfessionalsinvolvedintheproject
9. RoleofServiceProviderintheproject(PutatickMarkinappropriateprojectcomponent)
RequirementAnalysis&BusinessProcess SystemDesign,Developmentand
a. b.
Reengineering Testing
c. Training,Handholding,Implementation d. PostImplementationSupport
DataCentreEstablishment,Management&
e.
Support
10. TechnologyUsed:a.Javab.DotNetc.COTSd.Other
11. Theprojectisimplemented:a.inaunitofficeb.Inallunitofficesofadepartment
c.StateWided.Nationwide
Page|129

III. ProjectRelevancyandComplexity
12. IsprojectrelevanttoGovernanceFinanceManagement(Yes/No)?:
13. ListofModules(PutatickMarkagainstcoveredmodule)
a. BudgetPlanning&Preparation b. DebtManagement
c. FundManagement d. Ways&MeansManagement
e. SchemeWiseExpenditureTracking f. MonitoringUtilizationCertificate(UC)
g. PensionManagement h. TeachersProvidentFund(TPF)
i. DocumentManagement j. Works&ForestBillProcessing&Accounts
k. EDisbursementofGovernmentClaims l. BillPreparation&OnlineSubmission
m. SanctionOrderRepository n. MobileBasedTransactionReporting
o. BudgetDecisionSupportSystems(BDSS) p. OnLineAudit&Inspection
q. OnlinePaymentRequestfromPLOperator r. VirtualTreasuryModule(CyberTreasury)
s. NPSMonitoring&ESS t. AnyOther(PleaseSpecify_____________)

14. ListofFunctionalIntegration(PutatickMarkagainstcoveredintegration)
a. b.
c. d.
Pleaseattachclientcertificate/testimonial
Date: Date:
Place: Place:
CompanySeal

Page|130

Form8:ProposedSolution
RFPNO:______________,Date:_______________
Technical approach, methodology and work plan are key components of the Technical
Proposal. You are suggested to present Approach and Methodology divided into the following
sections:
a. Understandingoftheproject(Howthesolutionproposedisrelevanttotheunderstanding)
b. Solution Proposed (Provide details about the Proposed Solution. Architecture of the
proposedsolutionshouldbedescribedindetail)
c. Technical Approach & Methodology (Provide details about the technical approach and
methodologyofimplementationofProposedSolution)
d. SuggestedInnovations
Date: Date:
Place: Place:
CompanySeal
Page|131

Form9:ProposedWorkPlan
RFPNO:______________,Date:_______________
CalendarMonths(<Year>)
No Activity1
1 2 3 4 5 6 7 8 9 10 11 12
1. Indicate all main activities of the assignment, including delivery of reports (e.g.: inception,
interim, and final reports), and other benchmarks such as Purchaser approvals. For phased
assignments indicate activities, delivery of reports, and benchmarks separately for each
phase.
2. Durationofactivitiesshallbeindicatedintheformofabarchart.
3. Thissheetshouldbepreparedyearwise.
Date: Date:
Place: Place:
CompanySeal
Page|132

Form10:TeamComposition
RFPNO:______________,Date:_______________
Days
Name Relevant Position/
Relevant Areaof Reporting committedfor
Sl of Experiencein Task
Qualification Expertise Position this
Staff Years Assigned
engagement
1 2 3 4 5 6 7 8

Date: Date:
Place: Place:
CompanySeal
Page|133

Form11:FormatofCVforProposedTechnicalStaffofBidder
RFPNO:______________,Date:_______________
1. Name:
2. Designation:
3. CompanyEmployeeID:
4. DateofBirth:
5. Contacttelephone: Mobile:
6. Email:
7. Address:
8. LanguageKnown:
Odia English Hindi

Read Write Speak Read Write Speak Read Write Speak
9. IdentityDocumentType&No:
10. EducationalQualification:
(_____)
B.E. M.C.A. M.B.A. M.Sc.
Other
11. TechnicalCertification(IfAny):
SunCertifiedJavaProgrammer(SCJP)
OracleCertificationProgram(OCP)
ProjectManagementProfessional(PMP)
CISCOCertifiedNetworkAdministrator(CCNA)
AnyOther(PleaseSpecify__________________)
12. TotalExperience(inYears): NoofyearswithcurrentOrgn.
13. CurrentJobResponsibilities
Page|134

14. SummaryofProfessionalExperience
NameoftheOrganisation FromDate ToDate Designation Responsibilities
15. SummaryofProjects(Last3Projects)
Relatedto
Nameofthe From To Client/ Technology Govt.Finance
Role
Project Date Date Location Architecture Management
(Yes/No)
16. TechnicalSkillset(PutatickMark):
a. Portal b. DecisionSupportSystem,BI
c. WorkflowManagement d. SystemIntegration,WebServices
SecuritySystem,DigitalSignature
d. AnyOther(________________________)
Integration
Date: Date:
Place: Place:
CompanySeal
Page|135

Form12:DeploymentofPersonnel
RFPNO:______________,Date:_______________
StaffinputinMonths(intheformofabarchart) Totalstaff
Sl NameoftheStaff manmonths
1 2 3 4 5 6 7 8 9 10 11 12 n proposed
1. Professional Staff the input should be indicated individually; for Support Staff it should be
indicatedbycategory
2. Monthsarecountedfromthestartoftheassignment.
a. PartTime
b. FullTime
Date: Date:
Place: Place:
CompanySeal
Page|136

AppendixIII:FinancialProposalTemplate
Form13:ComplianceSheetforFinancialProposal
RFPNO:______________,Date:_______________
Pleasecheckwhetherfollowinghavebeenenclosedintherespectivecovers,namely,FinancialBid.
a. BidLetter(Financial)
Yes/No
(IntheformatattachedatAppendixIII,Form14)
b. MasterRateChartofManpower
Yes/No
c. CostofSoftwareDevelopment&Integration
Yes/No
d. CostofTraining
Yes/No
e. CostofRollout
Yes/No
f. CostofHelpdiskOperation
Yes/No
g. CostofMaintenance&Support
Yes/No
h. CostofSoftwareEnhancementServices
Yes/No
i. FinancialProposal
Yes/No

Date: Date:
Place: Place:
CompanySeal
Page|137

Form14:BidLetter(FinancialBid)
<Location,Date>
To:
Bhubaneswar
Phone:06742390725
Fax:06742531142
Subject:SubmissionofthefinancialbidforDesign,Develop,ImplementandSupportofiFMSOdisha
DearSir/Madam,
We, the undersigned, offer to provide the Implementation services for Design, Develop,
ImplementandSupportiFMSOdishainaccordancewithyourRequestforProposal<<RFPNo.>>
dated <<Date>> and our Proposal (Technical and Financial Proposals). Our attached Financial
Proposalisforthesumof<<Amountinwordsandfigures>>.Thisamountisexclusiveofanytaxes
andduties.
1. PRICEANDVALIDITY
AllthepricesmentionedinourTenderareinaccordancewiththetermsasspecifiedintheRFP
documents. All the prices and other terms and conditions of this Bid are valid for a period of 5
yearsfromthedateofopeningoftheBid.
Weherebyconfirmthatourpricesdonotincludeanytaxesandduties.
Weunderstandthattheactualpaymentwouldbemadeaspertheexistingtaxratesduringthe
timeofpayment.
2. UNITRATES
Wehaveindicatedintherelevantformsenclosed,theunitratesforthepurposeofonaccountof
paymentaswellasforpriceadjustmentincaseofanyincreaseto/decreasefromthescopeof
workunderthecontract.
3. TENDERPRICING
We further confirm that the prices stated in our bid are in accordance with your Instruction to
BiddersincludedinTenderdocuments.
4. QUALIFYINGDATA
WeconfirmhavingsubmittedtheinformationasrequiredbyyouinyourInstructiontoBidders.In
Page|138

case you require any other further information/ documentary proof in this regard before
evaluationofourTender,weagreetofurnishthesameintimetoyoursatisfaction.
5. BIDPRICE
WedeclarethatourBidPriceisfortheentirescopeoftheworkasspecifiedinthe<ReferSection
No.>.ThesepricesareindicatedCommercialBidattachedwithourTenderaspartoftheTender.
6. PERFORMANCEBANKGUARANTEE
Wehereby declarethat incasethe contractisawardedtous,weshall submit thePerformance
BankGuaranteeasspecifiedintheForm23inAppendixIVofthisRFPdocument.
OurFinancialProposalshallbebindinguponussubjecttothemodificationsresultingfromContract
negotiations,uptoexpirationofthevalidityperiodoftheProposal,i.e.,[Date].
WeunderstandyouarenotboundtoacceptanyProposalyoureceive.
We hereby declare that our Tender is made in good faith, without collusion or fraud and the
informationcontainedintheTenderistrueandcorrecttothebestofourknowledgeandbelief.
WeunderstandthatourTenderisbindingonusandthatyouarenotboundtoacceptaTenderyou
receive.
Thankingyou,
Weremain,
Yourssincerely,
AuthorizedSignature:
NameandTitleofSignatory:
NameofFirm:
Address:
Page|139

Form15:MasterRateChartofManpower
RFPNO:______________,Date:_______________
Note: Bidder shall provide the unit rate chart of resource persons related to different services.
Bidder will fill in Rate in INR for each type of resource persons related to different services as
provided below. The rate must be exclusive of any taxes and duties. The taxes as appropriate &
applicablewouldbepaidattheprevalentrates.ValidityofPriceisforaperiodof5yearsfromthe
dateofletterofintent.
RateinRs. RateinRs.(inWords)
Sl. Items Unit
(inFigures)
SystemAnalyst/Software
Engineer/Maintenance&
SupportEngineer/System
A ManMonth
Administrator/Database
Administrator/DataCenter
Manager
B HelpDeskResource ManMonth
ImplementationEngineerfor
C ManMonth
Rollout
TrainingCost(for30trainees
D includingtravel,lodgingand TrainingDay
boardingwithinthestate)
Signatureofthewitness SignatureoftheTenderer
Date: Date:
Place: Place:
(CompanySeal)
Page|140

Form16:CostofSoftwareDevelopment&Integration
RFPNO:______________,Date:_______________
Note: BiddershallprovidethemodulewisecostofSoftwareDevelopmentandIntegration.TheUnit
andRateprovidedinItemAofForm15mustbeconsideredtocalculatetheAmountinthisform.The
Amountcolumnofthisform(Form16)mustbecalculatedas(RateofItemAofForm15XQuantity
ofForm16)ThisValidityofPriceisforaperiodof5yearsfromthedateofletterofintent.
Quantityin
AmountinRs.
Manmonth(in QuantityinMan
Sl Modules (infigures)
Figure) month(inWords)
=[QXForm15(A)]
=Q
1 BudgetPlanning&Preparation
2 DebtManagementSystem
PensionFinalizationand
3 preparationofPensionPayment
Order(PPO)
eDisbursementofgovernment
4
claims(Treasurydrawl)
eDisbursementofgovernment
5
claims(ChequeDrawl)
NPSmonitoringsystemincluding
6
ESSforthenewemployees
CentralizedNPSContribution
7
Uploading
Financialdatawarehouseand
8 BudgetDecisionSupport
Systems(BDSS)I
Online/OfflineBillSubmission&
9
IntegrationModule
VirtualTreasuryModule
10
(Integrationwithcybertreasury)
TreasuryBudgetPreparation&
11
DSSModuleIntegration
iOTMSPortalMobileBasedTax
12
PaymentIntegration
13 AccountCorrectioniniOTMS
SanctionOrderDatabase
Moduledevelopmentand
14
IntegrationwithPayment
module
BudgetDistributionAdvance
15
fromOCFModuleIntegration
Page|141

Quantityin
AmountinRs.
Manmonth(in QuantityinMan
Figure) month(inWords)
=[QXForm15(A)]
=Q
Bifurcationofstateshareand
16
centralsharefromCSP
17 FundManagementSystem
RBIIntegrationandMonitoring
18
ofWaysandMeans
Works&ForestBillprocessing
19
andAccountsgeneration
SchemeofConsolidatedfund
20 expendituretrackingincurred
outside/inside
BudgetDecisionSupport
21
Systems(BDSS)II
22 COwiseonlinereconciliation
23 AccountscorrectioniniOTMS
IntegrationwithWorksforest
24
accounts&WAMIS
iOTMSCPSMSportal
25
Integration
26 IntegrationwithHRMS
27 TeachersProvidentFund(TPF)
MonitoringandControlling
28
UtilizationCertificate(UC)
OnlinePaymentrequestfromPL
30
operator
31 OnlineAudit&Inspection
PaymentTPFModule
32
integration
TreasuryOnlinePayment
33 requestbyPLoperatorModule
Integration
MobilebasedPaymentand
34
Transactionreportingsystem
TOTAL
Date: Date:
Place: Place:
(CompanySeal)
Page|142

Form17:CostofTraining
RFPNO:______________,Date:_______________
Note: BiddershallprovidethemodulewisecostofTraining.TheUnitandRateprovidedinItemD
ofForm15mustbeconsideredtocalculatetheAmountinthisform.TheAmountcolumnofthisform
(Form16)mustbecalculatedas(RateofItemDinForm15XQuantityofForm17)ThisValidityof
Priceisforaperiodof5yearsfromthedateofletterofintent.
Quantityin Quantityin
AmountinRs.
TrainingDay TrainingDay
(inFigures) (inWords)
=[Form15(D)XQ]
=Q
1 BudgetPlanning&Preparation
2 DebtManagementSystem
PensionFinalizationandpreparationof
3
PensionPaymentOrder(PPO)
eDisbursementofgovernmentclaims
4
(Treasurydrawl)
eDisbursementofgovernmentclaims
5
(ChequeDrawl)
NPSmonitoringsystemincludingESSforthe
6
newemployees
7 CentralizedNPSContributionUploading
FinancialdatawarehouseandBudget
8
DecisionSupportSystems(BDSS)I
Online/OfflineBillSubmission&Integration
9
Module
VirtualTreasuryModule(Integrationwith
10
cybertreasury)
TreasuryBudgetPreparation&DSSModule
11
Integration
iOTMSPortalMobileBasedTaxPayment
12
Integration
13 AccountCorrectioniniOTMS
SanctionOrderDatabaseModule
14 developmentandIntegrationwithPayment
module
BudgetDistributionAdvancefromOCF
15
ModuleIntegration
Bifurcationofstateshareandcentralshare
16
fromCSP
Page|143

Quantityin Quantityin
AmountinRs.
TrainingDay TrainingDay
(inFigures) (inWords)
=[Form15(D)XQ]
=Q
17 FundManagementSystem
RBIIntegrationandMonitoringofWaysand
18
Means
Works&ForestBillprocessingandAccounts
19
generation
SchemeofConsolidatedfundexpenditure
20
trackingincurredoutside/inside
21 BudgetDecisionSupportSystems(BDSS)II
22 COwiseonlinereconciliation
23 AccountscorrectioniniOTMS
IntegrationwithWorksforestaccounts&
24
WAMIS
25 iOTMSCPSMSportalIntegration
26 IntegrationwithHRMS
27 TeachersProvidentFund(TPF)
MonitoringandControllingUtilization
28
Certificate(UC)
30 OnlinePaymentrequestfromPLoperator
31 OnlineAudit&Inspection
32 PaymentTPFModuleintegration
TreasuryOnlinePaymentrequestbyPL
33
operatorModuleIntegration
MobilebasedPaymentandTransaction
34
reportingsystem
TOTAL
Date: Date:
Place: Place:
(CompanySeal)
Page|144

Form18:CostofPilotTesting&Rollout
RFPNO:______________,Date:_______________
Note: BiddershallprovidethecostofPilotTesting&RolloutoftheiFMSOdishasystem.TheUnit
andRateprovidedinItemCofForm15mustbeconsideredtocalculatetheAmountinthisform.The
Amountcolumnofthisform(Form18)mustbecalculatedas(RateofItemCinForm15XQuantity
ofForm18)ThisValidityofPriceisforaperiodof5yearsfromthedateofletterofintent.
QuantityinMan AmountinRs.
month(inFigures) QuantityinMan (infigures)
Sl Component
month(inWords)
=Q =[Form15(C)XQ]
TotalCostofPilotTesting
1
&Rollout
Date: Date:
Place: Place:
(CompanySeal)
Page|145

Form19:CostofHelpdeskOperation
RFPNO:______________,Date:_______________
Note: BiddershallprovidethecostofHelpdeskOperationoftheiFMSOdishasystem.TheUnitand
Rate provided in ItemB of Form 15 must be considered to calculate the Amount in this form. The
Amountcolumnofthisform(Form19)mustbecalculatedas(RateofItemBinForm15XQuantity
ofForm19).ThisValidityofPriceisforaperiodof5yearsfromthedateofletterofintent.
QuantityinMan Quantityin AmountinRs.

month(inFigures) Manmonth(in
Sl Component (infigures)
Words)
=Q =[Form15(B)XQ]
1 TotalCostofHelpdeskOperation
Date: Date:
Place: Place:
(CompanySeal)
Page|146

Form20:CostofMaintenance&Support
RFPNO:______________,Date:_______________
Note: BiddershallprovidethecostofMaintenance&SupportoftheiFMSOdishasystem.TheUnit
Amountcolumnofthisform(Form20)mustbecalculatedas(RateofItemAinForm15XQuantity
Quantityin Quantityin AmountinRs.

Manmonth Manmonth(in
Sl Component (inFigures) Words) (infigures)
=Q =[Form15(A)XQ]
TotalCostofMaintenance&
1
Support
Date: Date:
Place: Place:
(CompanySeal)
Page|147

Form21:CostofSoftwareEnhancementServices
RFPNO:______________,Date:_______________
Note: BiddershallprovidethecostofSoftwareEnhancementservicesforonemonthonly.TheUnit
Amountcolumnofthisform(Form21)mustbecalculatedas(RateofItemAinForm15XQuantity
AmountinRs.
Quantityin
(infigures)
Sl Component (ManMonth)
=[Form15(A)X
=Q
Q]
CostofSoftwareEnhancementServicesforonemonth
1 1
(30days)
Date: Date:
Place: Place:
(CompanySeal)
Page|148

Form22:FinancialProposal
RFPNO:______________,Date:_______________
Note:Bidder shall fill up all the Forms from 16 to 21 before filling in this form. The amount is
exclusiveofanytaxesandduties.Thetaxesasappropriate&applicablewouldbepaidatthe
prevalentrates.ValidityofPriceisforaperiodof5yearsfromthedateofletterofintent.
Reference
Items AmountinRs.
FormNo
Form16 TotalcostofSoftwareDevelopment&Integration
Form17 TotalcostofTraining
Form18 TotalcostofPilotTesting&Rollout
Form19 TotalcostofHelpDeskOperation
Form20 TotalcostofMaintenance&Support
Form21 CostofSoftwareEnhancementServicesforonemonth
TOTAL(inFigures)
Date: Date:
Place: Place:
(CompanySeal)
Page|149

AppendixIV:TemplateforPBG
Form23:PerformanceBankGuarantee
PERFORMANCESECURITY:
Bhubaneswar
Phone:06742390725
Fax:06742531142
Whereas,<<nameofthesupplierandaddress>>(hereinaftercalledthebidder)hasundertaken,in
pursuance of contract no. <Insert Contract No.> dated. <Date> to provide services for Design,
Develop,Implement&SupportofIntegratedFinanceManagementSystemOdisha(iFMSOdisha)to
DirectorofTreasuriesandInspection,Odisha,Bhubaneswar(hereinaftercalledthebeneficiary)
Andwhereasithasbeen stipulatedbyinthesaidcontractthatthebiddershall furnishyouwitha

bankguaranteebyarecognizedbankforthesumspecifiedthereinassecurityforcompliancewithits
obligationsinaccordancewiththecontract;
Andwhereaswe,<NameofBank>abankingcompanyincorporatedandhavingitshead/registered
officeat<AddressofRegisteredOffice>andhavingoneofitsofficeat<AddressofLocalOffice>have
agreedtogivethesuppliersuchabankguarantee.
Now, therefore, we hereby affirm that we are guarantors and responsible to you, on behalf of the
supplier,uptoatotalofRs.<InsertValue>(Rupees<InsertValueinWords>only)andweundertake
topayyou,uponyourfirstwrittendemanddeclaringthesuppliertobeindefaultunderthecontract
and without cavil or argument, any sum or sums within the limits of Rs. <Insert Value> (Rupees
<Insert Value in Words> only) as aforesaid, without your needing to prove or to show grounds or
reasonsforyourdemandorthesumspecifiedtherein.
Weherebywaivethenecessityofyourdemandingthesaiddebtfromthebidderbeforepresenting
uswiththedemand.
Wefurtheragreethatnochangeoradditiontoorothermodificationofthetermsofthecontractto
beperformedthereunderorofanyofthecontractdocumentswhichmaybemadebetweenyouand
theBiddershallinanywayreleaseusfromanyliabilityunderthisguaranteeandweherebywaive
noticeofanysuchchange,additionormodification.
ThisGuaranteeshallbevaliduntil<<InsertDate>>
Page|150

Notwithstandinganythingcontainedherein:
I. Our liability under this bank guarantee shall not exceed Rs. <Insert Value> (Rupees <Insert
ValueinWords>only).
II. Thisbankguaranteeshallbevalidupto<InsertExpiryDate>)
III. It is condition of our liability for payment of the guaranteed amount or any part thereof
arising under this bank guarantee that we receive a valid written claim or demand for
payment under this bank guarantee on or before <Insert Expiry Date>) failing which our
liabilityundertheguaranteewillautomaticallycease.

(AuthorizedSignatoryoftheBank)
Seal:
Date:
Page|151

RFP iFMS Odisha

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RFP iFMS Odisha

Transféré par

Droits d'auteur :

Formats disponibles

REQUESTFORPROPOSAL

RFP for Design, Develop, Implement and Support iFMSOdisha

Section5.4.2 RFP can be Downloaded from https://www.odishatreasury.gov.in or

Location Transparency: Since scalability is a key requirement, each business

Interoperability: With usage of open Standards and availability of discovery

Functional Rationalization and Reuse: Services can be granular in order to provide

Open standard based solution technology standards to be used: As much as possible

Useofworkflowbasedprocessing:Theproposed systemwillbe usedbydepartment

Performance has many dimensions; while adherence to functional & nonfunctional

Reliability, meaning, the probability of failurefree system operation for a specified

Maintainability, meaning, the probability of performing a successful repair action

HTTP/HTTPS SOAPoverHTTPS FTP/SFTP

Theintegrationarchitectureunderlinestherequirements fromtheproposedsystem forensuring

Use of open or industry standard based message exchange protocols to ensure

Databaseserveraccessshallbeprovidedthroughappropriate accesscontrol mechanism.

Users should be granted access to information, data, devices, processes/daemons, audit

Prepare the detailed User Requirement Specification (ToBeProcess) document and

Preparedetailed SRSdocument as perthe ToBe Process documentand broadlevelSRS.

Seek approval of detailed SRS document (including prioritization of software modules)

Sl. Description Quantity

Sl. STEP ACTOR

7 Capability to Print Entire Budgetary Book and other statutory

Sl. STEP ACTOR

6 P&C Department accept the actual expenditure data of the past

1 Guarantee detail capture against loan amount requested from

3 Actual Loan Taken and schedule of repayment generated against

4 Repayment (principal & interest) capture of actual loan taken will

Sl. STEP ACTOR

2 Generate demand statements/communications for individual loan

Sl. STEP ACTOR

1 Based on sanction order, creation of loan profile providing loan id

2 Generate demand statements/communications for individual loan

Sl. STEP ACTOR

2 Outstanding Loans/ advance from Govt. of Odisha and its

3 Generate demand statements/communications for individual loan

Sl. STEP ACTOR

Sl. STEP ACTOR

Sl. STEP ACTOR

2 Treasury shall unencrypt escrolls. The iOTMS will identify any

5 Link Bank shall prepare electronic Day wise Monthly Statement (e

Sl. STEP ACTOR

1 FD shall have availability of the financial information from its own

Sl. STEP ACTOR

1 Details such as beneficiary scheme, amount, the mode of transfer,

2 RBI is responsible for crediting to the consolidated funds of the

6 Reconciliation will be done against the various transaction entered

Sl. STEP ACTOR

2 CO will consolidate the expenditure; scheme wise/chart of account

Sl. STEP ACTOR

10 PIA examines the information as per the provision of the pension

Sl. STEP ACTOR

7 A yearly interest calculation will be done by the system for both

Sl. STEP ACTOR

Sl. STEP ACTOR

1 Junior Engineer (JE) prepares the bill in accordance with the

Sl. STEP ACTOR

7 Executive Engineer or Cashier can do a transfer entry (TE) for ExecutiveEngineer

8 The EE/Divisional Officer may also cancel, an issued cheque if

9 An advice list based on the issued cheque, will be generated

Sl. STEP ACTOR

Before submission of hardcopy bill to treasury, DDO will login into

DDO in case of treasury drawl will prepare the beneficiary list in a

In case of offline entry, DDO will manually send excel formatted