release order pplication system...

The contents of this document are the proprietary information is between eGramIT and SSAAT and may not be copied, distributed or reverse engineered without prior written permission from eGramIT.

RELEASE ORDER APPLICATION SYSTEM REQUIREMENT SPECIFICATION

VERSION 1.6

Submitted to

Food Corporation of India FCI Head Quarters Barakhamba Road New Delhi

Copy to

National Informatics Centre. CGO Complex New Delhi

Submitted by

eCentric Solutions Pvt. Ltd N161-A, 2nd Floor, Saira Tower Yusuf Sarai, Green Park New Delhi – 110049 www.e-centricsolutions.com

Reference: Work Order No: W1460017 Project No: P131782MPND

2 2 J U N E 2 0 1 5

http://e-centricsolutions.com/

System Requirement Specification Ver 1.6

©2015 Food Corporation of India, Govt. of India. All rights reserved.

2

Disclaimer

This SRS includes data that shall not be disclosed outside the client and shall not be duplicated, used or disclosed in whole or in part for any purpose other than to evaluate this proposal. If, however, a contract is awarded to FCI as a result of, or in connection with, the submission of this data, FCI shall have the right to duplicate, use or disclose the data to the extent provided in the resulting contract. This restriction does not limit the FCI’s right to use the information contained in this data if it is obtained from another source or provided by client.



3

TABLE OF CONTENTS

1. INTRODUCTION ................................................................................................................................................................. 9

1.1 ABOUT ECENTRIC ...................................................................................................................................................................... 9 1.2 ABOUT FOOD CORPORATION OF INDIA ........................................................................................................................................ 10 1.3 ABOUT NATIONAL INFORMATICS CENTRE ..................................................................................................................................... 11 1.4 ABOUT THE PROJECT ................................................................................................................................................................ 11 1.5 PURPOSE & SCOPE OF THE DOCUMENT........................................................................................................................................ 11 1.6 INTENDED AUDIENCE ................................................................................................................................................................ 12 1.7 STAKEHOLDERS ....................................................................................................................................................................... 12 1.8 REFERENCES ........................................................................................................................................................................... 12 1.9 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................................................................................. 13

2. EXECUTIVE SUMMARY .................................................................................................................................................... 13

2.1 ABOUT RELEASE ORDER ............................................................................................................................................................ 14 2.2 EXISTING SYSTEM .................................................................................................................................................................... 15

2.2.1 Release Order Operations - Manual .......................................................................................................................... 15 2.2.2 External Applications – Runs Independently ............................................................................................................. 16 2.2.3 Weighbridges – Stand alone - Vender Specific – Different Makes & Models ............................................................ 16

2.3 PROPOSED SYSTEM .................................................................................................................................................................. 17 2.3.1 Objectives .................................................................................................................................................................. 18 2.3.2 Outcomes .................................................................................................................................................................. 18 2.3.3 Assumptions .............................................................................................................................................................. 19 2.3.4 Dependencies ............................................................................................................................................................ 19

3. REQUIREMENTS STUDY ................................................................................................................................................... 20

3.1 VISITED LOCATIONS .................................................................................................................................................................. 20 3.2 OBJECTIVE OF STUDY ................................................................................................................................................................ 23 3.3 UNDERSTANDING THE EXISTING SYSTEM ...................................................................................................................................... 24

3.3.1 Project Stakeholders with Roles & Responsibilities ................................................................................................... 24 3.3.2 Schemes .................................................................................................................................................................... 27 3.3.3 Release Order Steps .................................................................................................................................................. 32 3.3.4 Release Order Parameters ........................................................................................................................................ 34 3.3.5 External Applications................................................................................................................................................. 36

3.4 APPLICATION PROSPECTIVE ........................................................................................................................................................ 38 3.4.1 Release Order process steps ...................................................................................................................................... 38 3.4.2 Release Order Initiation ............................................................................................................................................ 39

3.4.2.1 Allocation Process .............................................................................................................................................................. 39 3.4.2.2 Indent Generation ............................................................................................................................................................. 43

3.4.3 Release Order Generation steps ................................................................................................................................ 44 3.4.4 Release Order Execution steps .................................................................................................................................. 46 3.4.5 Release Order Diversion Steps ................................................................................................................................... 47 3.4.6 Release Order Extension Steps .................................................................................................................................. 48 3.4.7 Release Order Reimbursement steps ........................................................................................................................ 50 3.4.8 Release Order Operations at Delhi ............................................................................................................................ 51

3.4.8.1 Bulk Parties ........................................................................................................................................................................ 51 3.4.8.2 Small Traders ..................................................................................................................................................................... 52 3.4.8.3 Kendriya Bhandar .............................................................................................................................................................. 53

4. PROPOSED BUSINESS SOLUTION ..................................................................................................................................... 54

4.1 RELEASE ORDER ARCHITECTURE ................................................................................................................................................. 54 4.2 FUNCTIONAL REQUIREMENTS ..................................................................................................................................................... 55

4.2.1 Workflow Engine ....................................................................................................................................................... 55



4

4.2.1.1 Allocation ........................................................................................................................................................................... 56 4.2.1.2 indent ................................................................................................................................................................................ 60 4.2.1.3 Release Order .................................................................................................................................................................... 67 4.2.1.4 Inflow ................................................................................................................................................................................. 71 4.2.1.5 Outflow .............................................................................................................................................................................. 78 4.2.1.6 Diversion ............................................................................................................................................................................ 85 4.2.1.7 Extension ........................................................................................................................................................................... 86 4.2.1.8 Stock Processing ................................................................................................................................................................ 90 4.2.1.9 NCDEX RO .......................................................................................................................................................................... 92 4.2.1.10 RO Reimbursement............................................................................................................................................................ 93

4.2.2 Data Exchange Engine ............................................................................................................................................... 94 4.2.3 Web Portal ................................................................................................................................................................ 95

4.2.3.1 Functional Requirements ................................................................................................................................................... 95 4.2.3.2 User Interface Requirements ............................................................................................................................................. 97 4.2.3.3 General Requirements ..................................................................................................................................................... 131

4.2.4 Database Requirements .......................................................................................................................................... 131 4.2.4.1 Determine the tables ....................................................................................................................................................... 131 4.2.4.2 Determine the fields you need in the tables ................................................................................................................... 132 4.2.4.3 Identify fields with unique values .................................................................................................................................... 132 4.2.4.4 Normalization .................................................................................................................................................................. 132 4.2.4.5 determine the relationships between tables ................................................................................................................... 133 4.2.4.6 Create Masters Data and Basic Data to Run the Application ........................................................................................... 133 4.2.4.7 Identify Sharing Fields ...................................................................................................................................................... 134 4.2.4.8 Backup & Maintenance .................................................................................................................................................... 134

4.3 BEHAVIORAL REQUIREMENTS – SYSTEM LEVEL ............................................................................................................................ 135 4.3.1 Use Case View ......................................................................................................................................................... 135

4.3.1.1 Release Order Process ..................................................................................................................................................... 135 4.3.1.2 Release Order Initiation ................................................................................................................................................... 136 4.3.1.3 Release Order Generation ............................................................................................................................................... 137 4.3.1.4 Release Order Execution .................................................................................................................................................. 138 4.3.1.5 Release Order Closing & Other Scenarios ........................................................................................................................ 139

5. NON FUNCTIONAL REQUIREMENTS ............................................................................................................................... 139

5.1 PERFORMANCE REQUIREMENTS................................................................................................................................................ 139 5.2 SAFETY AND SECURITY REQUIREMENTS ...................................................................................................................................... 140 5.3 SOFTWARE QUALITY ATTRIBUTES .............................................................................................................................................. 140

5.3.1 High Availability ...................................................................................................................................................... 140 5.3.1.1 Infrastructure Level – NIC ............................................................................................................................................... 140 5.3.1.2 Software level .................................................................................................................................................................. 140

5.3.2 Scalability ................................................................................................................................................................ 141 5.3.3 Interoperability ........................................................................................................................................................ 141 5.3.4 Usability .................................................................................................................................................................. 142 5.3.5 Extensibility ............................................................................................................................................................. 142 5.3.6 Maintainability ........................................................................................................................................................ 143 5.3.7 Uniformity of parameter ......................................................................................................................................... 143

5.4 USER GROUPS WITH ACCESS LEVELS .......................................................................................................................................... 145 5.5 APPLICATION ENVIRONMENT ................................................................................................................................................... 146

5.5.1 Client Environment .................................................................................................................................................. 146 5.5.1.1 Operating System ............................................................................................................................................................ 146 5.5.1.2 System Configuration ...................................................................................................................................................... 146 5.5.1.3 Supported Browsers ........................................................................................................................................................ 146

5.5.2 Development Environment ...................................................................................................................................... 146 5.5.2.1 Operating system ............................................................................................................................................................. 146 5.5.2.2 System Configuration ...................................................................................................................................................... 147 5.5.2.3 Software .......................................................................................................................................................................... 147

5.5.3 Deployment Environment........................................................................................................................................ 147 5.6 IMPLEMENTATION APPROACH .................................................................................................................................................. 148

5.6.1 Implementation Strategy ........................................................................................................................................ 148



5

5.6.2 Execution Plan ......................................................................................................................................................... 149 5.7 CAPACITY BUILDING & USER TRAINING ...................................................................................................................................... 149

6. APPENDIX A - DATA DICTIONARY .................................................................................................................................. 150

7. APPENDIX B - GROUP LOG ............................................................................................................................................. 151

8. APPENDIX C - REFERENCE DOCUMENTS & PHYSICAL COPIES ......................................................................................... 151



6

TABLE OF FIGURES (Flowcharts, Screens & Reports)

Figure 1: FCI Offices .......................................................................................................................................................................... 10 Figure 2: Roles & Responsibilities ..................................................................................................................................................... 24 Figure 3: RO Process Steps ................................................................................................................................................................ 39 Figure 4: Allocation Process - Welfare Schemes ............................................................................................................................... 41 Figure 5: Allocation Process - Commercial Schemes ........................................................................................................................ 43 Figure 6: Indent Generation .............................................................................................................................................................. 44 Figure 7: RO Generation Process ...................................................................................................................................................... 45 Figure 8: RO Execution Process ......................................................................................................................................................... 47 Figure 9: RO Diversion Process ......................................................................................................................................................... 48 Figure 10: RO Extension Steps .......................................................................................................................................................... 49 Figure 11: Bulk Parties ...................................................................................................................................................................... 51 Figure 12: Small Traders ................................................................................................................................................................... 52 Figure 13: Kendriya Bhandar ............................................................................................................................................................. 53 Figure 14: Architecture ..................................................................................................................................................................... 55 Figure 15: Login Page ........................................................................................................................................................................ 98 Figure 16: Dashboard ........................................................................................................................................................................ 98 Figure 17: State Wise Allocation Page .............................................................................................................................................. 99 Figure 18: Add New Revenue District Wise Allocation Page ........................................................................................................... 100 Figure 19: Update Revenue District Wise Allocation Page ............................................................................................................. 101 Figure 20: Generate Indent ............................................................................................................................................................. 102 Figure 21: Indent Approval ............................................................................................................................................................. 103 Figure 22: Make Payment ............................................................................................................................................................... 103 Figure 23: Make Offline Payment ................................................................................................................................................... 104 Figure 24: Pending for FAP Approval .............................................................................................................................................. 105 Figure 25: Approve Indent by Sales ................................................................................................................................................ 106 Figure 26: Release Order Creation .................................................................................................................................................. 107 Figure 27: Release Order Approval ................................................................................................................................................. 108 Figure 28: Gate Entry Token No ...................................................................................................................................................... 109 Figure 29: Inflow Token No ............................................................................................................................................................. 110 Figure 30: Weighbridge - Loaded Truck (Inflow) ............................................................................................................................. 111 Figure 31: Unit/Shed In-charge (Inflow) ......................................................................................................................................... 112 Figure 32: Generate Gate Pass (Exit) .............................................................................................................................................. 113 Figure 33: Empty Truck (Inflow) ...................................................................................................................................................... 114 Figure 34: Gate Exit (Inflow) ........................................................................................................................................................... 115 Figure 35: Empty Vehicle (Outflow) ................................................................................................................................................ 116 Figure 36: Generate Token ............................................................................................................................................................. 116 Figure 37: Gate Exit Loaded Truck .................................................................................................................................................. 117 Figure 38: Depot Manager Review & Approval .............................................................................................................................. 118 Figure 39: RO Diversion .................................................................................................................................................................. 119 Figure 40: RO Extension .................................................................................................................................................................. 120 Figure 41: NCDEX Release Order Digitization ................................................................................................................................. 121 Figure 42: NCDEX RO Approval ....................................................................................................................................................... 122 Figure 43: FAP Verification .............................................................................................................................................................. 123 Figure 44: Upgrade/Downgrade ..................................................................................................................................................... 124 Figure 45: Gain/Loss........................................................................................................................................................................ 124 Figure 46: Daily Deposit .................................................................................................................................................................. 125 Figure 47: FAP Approval .................................................................................................................................................................. 125 Figure 48: Gate Operator Inflow ..................................................................................................................................................... 125 Figure 49: Gate Operator Outflow .................................................................................................................................................. 126 Figure 50: Indent Approver ............................................................................................................................................................. 126 Figure 51: Area Sales Manager Report ........................................................................................................................................... 126 Figure 52: Indent Report ................................................................................................................................................................. 127



7

Figure 53: Release Order between Dates ....................................................................................................................................... 127 Figure 54: Release Order Approver................................................................................................................................................. 127 Figure 55: Release Order Creator ................................................................................................................................................... 128 Figure 56: Scheme Commodity Wise Issue ..................................................................................................................................... 128 Figure 57: Scheme Commodity Wise Issue Summary ..................................................................................................................... 129 Figure 58: Scheme Wise Issue ......................................................................................................................................................... 129 Figure 59: Issues off take ................................................................................................................................................................ 130 Figure 60: Statement of Issue ......................................................................................................................................................... 130 Figure 61: Use Case Release Order Process .................................................................................................................................... 135 Figure 62: Use Case Release Order Initiation .................................................................................................................................. 136 Figure 63: Use Case Release Order Generation .............................................................................................................................. 137 Figure 64: Use Case Release Order Execution ................................................................................................................................ 138 Figure 65: RO Closing & Other Scenarios ........................................................................................................................................ 139 Figure 66: Data Dictionary .............................................................................................................................................................. 150



8

Date Ver. No. Description Author Comments

01/07/2014 Ver. 1.0 Prepared based on Field Study

eCentric Team Initial Version shared with NIC for review and approval

21/07/2014 Ver. 1.1 Prepared based on Field Study

eCentric Team Edited by eCentric Team shared with NIC for review and approval

09/01/2015 Ver. 1.2 Based on discussion during development review

eCentric Team Edited by eCentric Team shared with NIC for review and approval


eCentric Team Edited by eCentric Team shared with FCI and NIC for review and approval


eCentric Team Edited by eCentric Team shared with FCI and NIC for review and approval


eCentric Team Reviewed and Approved by FCI

19/05/2015 Ver. 1.5 SRS Modification based on the review comments shared in the FAP meeting. Please refer the below section for details:

a) a) Section 4.2.1 for

Workflow engine

b) b) Section 4.2.3.2 for

Screens and Reports

eCentric Team Submit for final approval

19/06/2015 Ver. 1.6 SRS modification based on the following : 1) Feed Back received from Sales Team 2) Review Comments by IUG members during SRS finalization meetings dated 12th June 2015 & 16th June 2015

eCentric Team Submitted for sign off



9

1. INTRODUCTION

1.1 ABOUT ECENTRIC

eCentric Solutions Pvt. Ltd., (eCentric) part of Paradigm Group is one of the fastest growing Information Technology Company. Established in 2002, eCentric is a Total IT solution company with an enviable client list that includes Fortune 500, US Government and Indian Government Clients. eCentric has seen more than 100% growth in resources and revenues right from the first year of its operations. Our rich process development history and experience in partner engineering services position us to provide superior development, testing and support services to the client. We follow mature execution processes to ensure higher predictability, higher quality and lower risk. eCentric leverages its specialized resource pool and superior technology to deliver services with superior quality and economics. We adhere to the highest industry standards and adopt best practices and we are ISO-9001-2008, CMMI Level 5 accredited and Six Sigma compliant. eCentric provides services and solutions in every key area of information technology and management. The services and solutions are conceived and developed to provide a competitive edge to our Client's business. Our service range includes but not limited to:

Application Engineering

Application conversion / migration

Product Engineering

Product Implementation and deployment

Enterprise Content Management and Portals (ECMP)

GIS Consulting

Quality Assurance Testing

ITES / BPO Services

Web Site: www.e-centricsolutions.com

eCentric is an implementation agency responsible for executing automation of Release Order Process application for Food Corporation of India (FCI) through National Informatics Centre (NIC).

Contact Details

Sr. No. Particulars eCentric (Implementation Agency)

1. Name Abhishek Mishra

2. Phone +91 11 43332301

3 E-mail Address [email protected]

4 Mobile 91 9899763881

http://www.e-centricsolutions.com/



10

1.2 ABOUT FOOD CORPORATION OF INDIA The Food Corporation of India (FCI) was incorporated under the Food Corporation Act, 1964 with the function of undertaking purchase, storage, movement, transportation, distribution and sale of food grains on behalf of the Government of India (GOI). It is an agency under the administrative supervision and control of the Ministry of Consumer Affairs, Food and Public Distribution, Department of Food and Public Distribution (Ministry) which is responsible for implementation of the national food security system. FCI aims at fulfilling the following objectives:

providing price support operations through procurement for safeguarding the interests of the farmers

Making food grains available and accessible at reasonable price to weaker and vulnerable sections of society through Targeted Public Distribution System and other government schemes through efficient and cost effective movement, and distribution of food grains throughout the country

Maintaining satisfactory level of operational and buffer stocks of food grains to ensure national food security and to carry out price stabilization operations.

FCI Office

Figure 1: FCI Offices

FCI HQ

Zonal Offices - 5

Regional Offices - 24

District Offices - 170

FCI Depots – 2000 (Approx.)



11

1.3 ABOUT NATIONAL INFORMATICS CENTRE National Informatics Centre (NIC) of the Department of Electronics and Information Technology is providing network backbone and e-Governance support to Central Government, State Governments, UT Administrations, Districts and other Government bodies. It offers a wide range of ICT services including Nationwide Communication Network for decentralized planning, improvement in Government services and wider transparency of national and local Governments. NIC assists in implementing Information Technology Projects, in close collaboration with Central and State Governments, in the areas of (a) Centrally sponsored schemes and Central sector schemes, (b) State sector and State sponsored projects, and (c) District Administration sponsored projects. NIC endeavors to ensure that the latest technology in all areas of IT is available to its users. Specific to the Release Order application, National Informatics Centre (NIC) acts a nodal agency between the Food Corporation of India and the eCentric which can take care about the following activities

1. Overall project coordination, monitoring and supervision of the project. 2. Technical assistance to understand the External applications. 3. Deliverables validation and UAT. 4. To provide the infrastructure (both hardware and software licenses) help the agencies to test and deploy the

application in test and production environment. 5. To provide the technical assistance and complete the project as per the proposal and plan.

6. To help he Implementation agency in application Integration with External applications.

7. To Support the Implementation agency for application deployment and testing.

1.4 ABOUT THE PROJECT Release Order Application (RO) is an initiative by Food Corporation of India (FCI) intended to provide an integrated workflow system to perform the Release Order Operations online. The purpose of this application is to automate the existing Release Order Operations. It can exchange the information electronically with their stakeholders involved in the Release Order Operations including the State Agencies/Parties. It also expected to provide online reports to track and monitor the progress of Release Order Operations through online web portal.

1.5 PURPOSE & SCOPE OF THE DOCUMENT This document specifies the requirements for the proposed FCI Release Order Application (RO) in detail. The scope of this document includes the description of the existing system and functional interface requirements for the proposed system. It also talks about non functional requirements like security, performance, quality, training and other requirements as part of the Release Order Application. It helps the department to verify whether the functional requirements have been documented here completely, accurately and unambiguously to meet the Release Order Operations.

To help the department to check if proposed system functional needs are addressed completely and correctly.

To provide a foundation to implementation agency to design and develop the proposed System.



12

To provide input into the design and development phase of the proposed Release Order application.

To describe what the proposed system will do.

1.6 INTENDED AUDIENCE The main intended audience for this document is the project stakeholders specially District offices of FCI (Food Corporation of India), Functional Heads, Depot officials involved in executing Release Orders, State Govt. Agencies & officials involved in Release Order operations and any other concerned officials. Implementation Agency Team (Project Manager, Data Architects, Application Architects and Technical Architects and Development Team) would also find the information in this document useful when they need to finalize the design, solution and develop the business logic to implement the Release Order Application. The requirement documented herein is technology-independent and this would help the project stakeholders to comprehend the requirements fairly easily from this document.

1.7 STAKEHOLDERS

Stakeholders are the individuals or groups who are participants of the Release Order operations and whose requirements need to be considered throughout the project. This section lists the Release Order application stakeholders for which System requirements are documented.

1. FCI Head Quarters 2. FCI Zonal Office 3. FCI Regional Office 4. FCI District Office 5. FCI Depot Office 6. State Agencies/Parties 7. NIC 8. Implementation Agency (eCentric)

1.8 REFERENCES System Requirement Document was prepared by Implementation Agency, M/s eCentric Solutions Pvt. Ltd based on a result of DPR Study, Field visits to FCI stakeholder offices and subsequent meetings/discussions with the NIC team and FCI User group. This section lists the references to previous documentation, correspondence that are helpful to come up with System Requirement Specification.

DPR document developed by NIC

Field Study at FCI stakeholder locations.

Discussions with Project stakeholder departments (FCI and NIC)

Field Survey & Feedback Reports

External Applications study with NIC and FCI officials

Review and Discussion meetings with NIC and FCI Officials



13

Physical Ledgers/Forms

1.9 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

S.No. Abbreviation Description

1. AAY Antoyodya Anna Yojana

2. AFSO Assistant Food Supply Officer

3. AM Area Manager

4. AO Allocation Order

5. APL Above Poverty Line

6. BPL Below Poverty Line

7. CAF&PD Consumer Affairs, Food and Public Distribution

8. CWC Central Warehousing Corporation

9. DD Demand Draft

10. DFSO District Food Supply Officer

11. DM District Manager

12. DOF&PD Department of Food and Public Distribution

13. CSC State Civil Supply Corporation

14. F&S Food & Supply

15. FAP Financial Accounting Package

16. FCI Food Corporation of India

17. FPS Fair Price Shop

18. GOI Government of India

19. MDM Mid Day Meal

20. MSP Minimum Support Price

21. NIC National Informatics Centre

22. OMSS Open Market Sale Scheme

23. PDS Public Distribution System

24. RO Release Order

25. RTGS Real Time Gross Settlement

26. SGRY Sampoorna Grameen Rozgar Yojana

27. SWC State Warehousing Corporation

28. TPDS Targeted Public Distribution System

29. WCM Weigh Check Memo

2. EXECUTIVE SUMMARY Food Corporation of India (FCI) disburses commodity to State Agencies /Government Departments/nominated agencies / Wholesale Dealers / Fair Price Shops under various schemes based on guidelines provided by Ministry of Consumer Affairs, Food & Public Distribution. All these disbursals are based on the payments made by the respective Parties / Customers. On every payment by the Party, FCI District Office creates a document called ‘RELEASE ORDER’ – a document which authorizes the party / customer to receive commodity from the FCI depots designated by the FCI District Office.



14

2.1 ABOUT RELEASE ORDER Release Order is an authorized document generated by Sales Department of FCI district office on the payment made by the respective State parties like State agencies and other private agencies. It facilitates the respective State Agencies /Parties to lift the commodity from FCI depots. The major activities involved in Release Order process are as follows.

1. Department of Consumer Affairs, Food & Public Distribution (CA,F&PD). Government of India (GOI) receives

the food grain requirements from the State food departments to implement the welfare schemes.

2. Department of Consumer Affairs, Food & Public Distribution (CA,F&PD). Government of India (GOI) defines

policies/guidelines to allocate the food grains under various schemes for State agencies/parties on need

basis.

3. Department of Consumer Affairs, Food & Public Distribution (CA,F&PD). Government of India (GOI) allocate

commodities to the State under various schemes and send the State wise allocation orders with guidelines

to Food Corporation India and respective State/Central government agencies responsible for implementing

the scheme. Further, commodities allocated FCI Revenue District wise by respective State Govt.

4. State Agency/Party make payments to Food Corporation of India for allotted quantity based on the Central

issue prices (state wise, scheme wise, crop year & commodity) / issue price(OMSS & Commercial) as

decided by Govt. of India.

5. FCI receives payments along with requisition / indent from the State Agencies / Party / Customer – through

DD / NEFT / RTGS.

6. Payment Confirmation by FCI Account Section. Excess payments / Earnest Money Deposit / Sale Deposit by

the State Agencies/parties adjusted against the cost of the current Release Order.

7. FCI sales/commercial section assigns the depot based on stocks availability and Release Order is issued to

the Respective State Agencies/Parties.

8. State Agency/Party will lift the commodities from designated FCI Depots against Release Order.

9. Lifted food grains are weighed at the weighbridges.

10. Reconciliation of Release Orders against the Issues.

11. Closure of Release Order – after entire quantity is lifted by the party.

12. Diversion of Release Order – identification of alternate FCI depots in case of the initially identified depot

runs out of stock, at the request of State Govt. or any other operational/ natural exigencies.

13. Extension of Release Order – extension of the validity period.

14. Release Order Reimbursement - Calculate the Reimbursement amount against un-lifted quantity and

adjustment of payments.



15

2.2 EXISTING SYSTEM The existing Release Order operations are completely manual at all the project stakeholder locations. The communications between stakeholders are through papers/documents/ledgers. Therefore, data/information exchange for Release Order business transaction and data sync with external applications take place manually. It results in re-entry of data into their internal/dependent systems and the increase in the dwell time for the Release Order operations. The existing applications FEAST, DCMS, IRRS, SIMS, FAP and other external applications used to handle the other functional areas and using in good extent in many of the FCI District offices and Depots, the stakeholders are unable to get the expected benefits due to the lack of holistic approach towards the automation and the disconnects resulted from the lack of common platform for data exchange. The existing IT infrastructure and environmental conditions at the depots are not meeting the requirements to use the existing applications. These problems are summarized below based on the Release Order functional process.

2.2.1 RELEASE ORDER OPERATIONS - MANUAL

1. Existing Release Order is not being generated in predefined standard format. Most of the FCI District Offices use

their customized format to generate the Release Order.

2. Format of release order differs for various schemes like PDS, MDM, Defense and OMSS (D) etc.

3. The project stakeholders are not adapting FCI prescribed formats/guidelines as part of Release Order operations

in all the locations.

4. Allocation demand submitted by district Food and Supply Corporation is not following a standard format. Each

agency follows their own format for generating allocation demand or indent. Indents may also cater allocation

against State driven PDS schemes. Although FCI can create Release Order only against schemes defined by GOI

like AAY, BPL, APL, MDM and Other Welfare and Non Welfare Schemes.

5. Existing release order process does not have any mechanism to identify discrepancy quantity mentioned in

allocation order and indent received from State agency. There is possibility of human error while generating

Release Order.

6. Delay in Release Order generation due to non-availability of online information to verify and validate the indent

details submitted by the State Agency/Party.

7. State agency/Party prepares Indent against an allocation order and sends it to FCI District office for issuing

Release Order but these agencies are not able to track the progress of their request.

8. The communication between State agency and Depot office to decide the schedule for lifting of commodity is

mostly informal, over telephone.

9. Release Order does not have any unique hologram to avoid any fudging.

10. Reconciliation of off-take v/s allocation on day to day basis is not possible due to non-availability of daily

transactions information online.



16

11. Stakeholders still need to submit paper documents in many places (Depot/State Agency/Party) since either

existing applications are not accessible to the users due to non-availability of the infrastructure/manpower to

use the applications.

12. State agency/Party finds difficulty in getting day wise commodity lifting report from FCI depots.

13. State agency/Party sending hard copy of extension request to District office is unable to check the progress of

their request until final approval/ rejection happens.

14. The stakeholders are unable to track the Current Release Order Status during entire Release Order Workflow.

15. Existing manual operations are time consuming and error prone.

16. Release Order Parameters are entering repeatedly in different stages due to non-availability of digitized Release

Order details.

17. Due to lack of infrastructure and technical manpower at Depot, the FCI Depot officials are not using the online

applications.

18. Minimum IT infrastructure is available at most of the FCI owned depots, but depots managed/hired by FCI does

not have IT infrastructure to use the applications.

19. Reconciliation of off take data is difficult because data is spread across various physical registers.

20. There is no validation or verification mechanism to check whether lifted food grains from FCI Depot reached to

desired destination point or not.

2.2.2 EXTERNAL APPLICATIONS – RUNS INDEPENDENTLY

1. The existing DCMS, IRRS, FAP, FEAST, SIMS and Weighbridge applications are running independently and data

synchronization is not happening online.

2. Existing external applications are running independently and application users are repeatedly entering the same

parameters manually in the applications separately based on data available in physical papers.

3. IRRS application maintains depot wise closing balances of commodity on daily basis however does not provide

the commodity inflow and outflow data captured by weighbridge that are available with unit in charge in issue

register (or WCM/M-Form) against the Release Order.

4. There is no verification and validation check for the entered data since the applications are running

independently.

5. Most of the applications do not have a provision to capture the Release Order number (i.e. IRRS, and

Weighbridge).

6. Most of the external applications are not maintaining the up to date information due to lack of Infrastructure

and manpower at stakeholder premises.

7. Some of the Applications like FEAST and SIMS are developed only for the TPDS Schemes.

2.2.3 WEIGHBRIDGES – STAND ALONE - VENDER SPECIFIC – DIFFERENT MAKES & MODELS 1. FCI Depots uses different weighbridges makes and models developed by different vendors. The vendor supplies,

installs and maintain the software and hardware concerned with the weighbridge.

2. The weighbridges are pre-installed with device specific applications to generate weights.

3. Infrastructure of weighbridge (like power backup) is meant to support their weighbridge equipments only.

Further load of any electronic devices or power is not feasible on existing infrastructure.



17

4. The computers used along with weighbridge are basic standard computers with minimal configuration which

may not support GUI intensive applications.

5. These computers are not exposed to internet to prevent virus and malicious software attacks.

6. Existing weighbridges uses the standalone applications and may not have the communication interfaces like

serial, USB ports etc. to capture parameters through external applications.

7. Weighbridges are either located inside or outside the Depots premises. Depots which do not have the

weighbridges within the premises, weighment is being done by private weighbridges.

8. Weighment details generated by weighbridges contain either two or five decimal places, i.e., either Kilo Grams

or Grams. Although FCI maintains issue/receipt quantity in grams but base unit of weighbridge is Kg and

tolerance level is (+/-)5 Kg.

9. Most of the FCI owned depots have electronic weighbridges installed. The status of the remaining depots is unknown.

10. All the Release Order execution steps are manual except the weighment details generated by weighbridge. 11. Except weighment parameters, all the other details like unit/shed number, bag type, numbers of bags,

commodity name are provided by unit in-charge.

12. Same parameters are repeatedly entered at different locations/places like Gate, weighbridge and at Unit/Shed.

13. Weighbridge software does not have a provision to capture the Release Order number.

14. Unit In-charge issues loose grains using beam scale.

15. Unit-in-charge uses 10% weighment method to weigh the food grains received in rail movement.

2.3 PROPOSED SYSTEM To overcome challenges in existing Release order operations Food Corporation of India, initiated the development of web based Release Order workflow automation system to perform the Release Order Operations. Release Order Application will provide a single window for the Food Corporation of India to perform the Release Order Operations online. It exchanges the information electronically across its stakeholders involved in the Release Order Operations supply Chain including the State Agencies/ Departments and Parties. It provides the external application interfaces to share the data in secure and efficient manner to perform the Release Order Operations as well as provides global visibility and access to the central Release Order database to all its stakeholders through web portal.

To develop a web enabled, work flow based application for Release Order with ability of linkages with DCMS, FEAST, DCMS, FAP and Weighbridge applications will enable a complete view of the inflow and outflow of the commodities and the stock position in the depot.

The application is built from scratch, and thus there is no initial foundation to build Release Order system upon. The proposed application will consist of development of backend solution and frontend applications. The backend will handle the storage of data pertaining to release order application and the frontend solution will allow the user to perform the Release Order operations remotely online. Following is the suggested approach to implement the Release Order application: 1. Online submission of Allocation Demand/Indent to be facilitated.

2. To develop commonly defined computerized work-flow for Release Order generation and execution process.



18

3. Employing appropriate authentication mechanisms of the release order such digital signature, in addition to the

software based login security mechanisms.

4. Uniform format of Release order document irrespective of scheme.

5. Uniform format of peripheral documents such as Weight Check Memo, Issue Register Gate pass etc.,

6. Appropriate IT infrastructure may be provided for executing the proposed solution at all project stakeholder

premises including depots.

7. Integration of external application like IRRS, FAP and Weighbridge Software with Release Order is mandatory to

complete the entire workflow of the Release Order Solution.

8. The proposed system should allow the FCI district officers to enter NCDEX generated Release Order fields in

offline mode using the input forms.

9. Integration of Weighbridge data with the Release Order application works in either online or offline mode.

10. Proposed System can be used in web enabled devices like laptops/tablets/smart phones with large screen size to

perform the Release Order operations.

2.3.1 OBJECTIVES The objectives of the proposed Release Order application are as follows. 1. To eliminate the manual process and automate the current Release Order operations. 2. To strengthen the Release Order processes and procedures. 3. To maintain uniformity and consistency in Release Order process at all locations in the country. 4. To link the external applications with DCMS, IRRS, FAP, FEAST, SIMS and weighbridge data to maintain the

consistency and uniformity. 5. To track the Release Order operations online. 6. To speed up the Release Order operations. 7. To eliminate the leakages in current Release Order processes. 8. To reconcile the stock positions online at depot level by integrating with Weighbridge applications. 9. To maintain data consistency and uniformity by integrating the dependency applications with Release Order. 10. To assure the State Agency/Party that lifted the correct quantities against the Release Order. 11. To eliminate most of the paper work.

2.3.2 OUTCOMES

Uniform workflow solution for release order operations irrespective of the scheme and State Agencies/Parties

Tracking and monitoring Release Order operations progress online through portal.

Exact depot wise off-take stock positions made available online.

Reduced the Release Order operations time and cost due to automation of the processes.

Reduced administrative burden and service fulfillment time & costs

Increases the transparency, accountability and efficiency as part of System Implementation.

Reduced manual interaction of project stakeholders with and encourage ‘e’-interaction and more efficient

communication.

To link it to the PDS Supply chain.



19

2.3.3 ASSUMPTIONS This section describes major assumptions that were made prior to or during the System 1. Release Order process steps are uniform across all FCI locations and adhere to FCI recommended guidelines. If

not, it is mandatory to follow FCI guidelines as part of Release Order operations. 2. External applications data like stock positions, designated depots etc., is accurate and up to date. 3. Existing external applications would be customized by the respective solution providers. 4. RO Application will define the protocol so that all the weighbridge system shall provide the necessary data and

linkages, based on standards as finalized by FCI (preferably by XML/CSV).

5. All the applications should maintain the uniform master tables and data exchange as per the codes instead of

the names.

6. FAP would follow existing payment validation and verification procedures.

7. All the financial transactions would be routed through FAP. Release Order application shall maintain only the

final status provided by FAP.

8. External applications are up and running 24/7 to maintain the live data sync.

9. All the project stakeholders have the appropriate infrastructure (hardware/software) to run the Release Order

application.

10. Infrastructure (system hardware and other connectivity devices) and software licenses to run the application can

be provided by the NIC.

11. Technical manpower is available to use the application at project stakeholder locations.

12. FCI would finalize and approve the required screens and reports for the proposed Release Order Application.

13. FCI would identify the pilot locations and provide the required infrastructure for POC Implementation.

14. NIC would provide the staging environment for POC study and testing.

15. FCI would provide the training officers details for capacity building.

16. Basic data and required masters to run the Release Order application would be provided by the Project

Stakeholders.

17. NIC would provide the support to linkage to existing e-Mail and SMS gateway systems with Release Order

application.

2.3.4 DEPENDENCIES 1. All the project stakeholders shall have the necessary infrastructure proposed by the Release Order application.

2. All the relevant data – master data , basic users data, static data, transactional data, etc., whatever needed by

the application, shall be provided by the concerned stake holders in a uniform standard format, within the

stipulated time, so that the work-flow processes functions uninterrupted.

3. FCI shall provide the necessary process details and the work-flows.

4. eCentric in consultation with NIC and FCI shall provide the format of the tabular parameters for the

graphical reports.

5. eCentric, need to take NIC & FCI’s approval over the portal screen design and input forms.

6. eCentric, in consultation with NIC and FCI shall freeze the requirements, in terms of input and output, and

formalize the same. Any change of requirement at a later stage of the development shall need a re-look on the

work-flow designed initially.



20

7. For integration Release Order application with external applications such as DCMS, IRRS, FAP, FEAST & SIMS etc.

shall provide the necessary data and linkages provision to capturing the Release Order Number.

8. For weigh bridge linkage, all the weighbridge vendors shall provide the necessary data and linkages, based on

standards proposed by Release Order application.

9. NIC shall provide the required infrastructure and connectivity to deploy the application at NIC Data Centre.

10. FCI shall conduct the User Acceptance Testing (UAT) before submitting the same for security audit.

11. The application for the purpose of third party audit can be hosted at NIC’s server and undergo security audit by

FCI.

12. The issues arising out of the security audit shall be fixed by the eCentric.

13. Hosting of the web enabled work flow based Release Order Application, in its entirety, shall be subject to the

security audit clearance by NIC.

14. The security audited application shall be co-located at one of the NIC’s server.

3. REQUIREMENTS STUDY

3.1 VISITED LOCATIONS To understand the Release Order Operations and Requirements, NIC has already visited the various depots and district offices of FCI in the Year 2012 and prepared the Detailed Project Report. For this purpose NIC team has visited seven States in India and interacted with Project stakeholders for getting the understanding of the FCI Release Order Operations. Team has visited offices of State agencies and other stakeholders to understand the end to end flow of Release Order Operational Process. The study had focused especially on Release Order Operations pertaining to TPDS schemes. National Informatics Center (NIC) of India had visited following locations and done the field study and prepared the Detailed Project Report on Release Order Operations.

State District Office/Depots Officers Met

Delhi Commercial Section, FCI Regional Office Asst. General Manager

FCI District Sales Office, Mayapuri

Area Manager

Manager Sales

Manager Accounts

FCI Depot, Mayapuri Depot Manager

Depot in-Charge

Quality Manager

Weighbridge In-Charge

Haryana Commercial Section, FCI Regional Office Asst. General Manager

FCI District Office, Kurukshetra Area Manager

Manager Sales

Manager Accounts

FCI Pipli Depot, Kurukshetra Depot Manager

Depot in-Charge

Quality Manager



21



Punjab FCI Regional Office Commercial Section Assistant General Manager

FCI District Office, Ludhiana Area Manager

Manager – Commercial

Manager – Finance

FCI Depot, Machhiwara, Ludhiana Depot In charge

Quality Manager

District Office PUNGRAIN, Ludhiana District Manager

Assistant Food supply Officer

Account Officer

Food Inspector

District Office PUNSUP, Ludhiana Assistant Food supply Officer

Account Officer Food Inspector

Bihar FCI Regional Office, Patna Asst. General Manager

FCI District Office, Patna Area Manager

Manager Sales

Manager Accounts

FCI Godown Phulwari Sharif, Patna Depot Manager

Depot in-Charge

Quality Manager


Assam FCI District Office, Guwahati Area Manager

Manager Sales

Manager Accounts

FCI Depot Guwahati Depot Manager

Depot in-Charge

Quality Manager


Guwahati Wholesale Consumer Co-op Society Ltd., Guwahati

Assistant Supply Officer

Kerala FCI District Office, Valiathura Area Manager

Manager Sales

Manager Accounts

FCI Depot Office, Valiathura Depot Manager

Depot in-Charge

Quality Manager


Kerala State Civil Supplies Corporation, Chalai Depot

Depot In-Charge

Chhattisgarh FCI District Office, Raipur Area Manager

Manager Sales

Manager Accounts

FCI Depot Office, Raipur Depot Manager

Depot in-Charge



22


Quality Manager


Chhattisgarh State Civil Supplies District Supply Officer

The requirements study conducted by eCentric, which covers all the schemes (TPDS/Welfare/Commercial - OMSS) as part of Release Order Operations, was a supplementary study to firm up and fine tune the requirements and prepare a detailed specification for designing and developing the Release Order Application. In this purpose, In MARCH 2014, eCentric team has visited Delhi – Mayapuri , Kazipet, Sanatnagar, Taranaka and Charlapally locations to understand the FCI Release Order Operations, and usage of External applications like DCMS, IRRS, FAP, FEAST, and Weighbridge. At Kazipet location eCentric studied the WINGs application functionality.


Delhi Commercial Section, FCI Regional Office Asst. General Manager

FCI District Sales Office, Mayapuri

Area Manager

Manager Sales

Manager Accounts

FCI Depot, Mayapuri Depot Manager

Depot in-Charge

Quality Manager


Andhra Pradesh FCI District Office, Kazipet Area Manager

Manager Sales

Manager Accounts

FCI Depot, Kazipet Depot Manager

Depot in-Charge

WINGs Developer


FCI District Office, SanathNagar Area Manager

Manager Sales

Manager Accounts

FCI Depot, Sanath Nagar Depot Manager

Depot in-Charge

WINGs Developer


FCI District Office, Taranaka Area Manager

Manager Sales

Manager Accounts

FCI Depot, Charlapally Depot Manager

Depot in-Charge




23

3.2 OBJECTIVE OF STUDY The main objectives of the requirement study were

Understand the business processes of the stakeholders and to see any changes to the process or information

flow given in the Detailed Project Report by NIC.

To identify the document/information exchange requirements between the project stakeholders.

Find out the current IT infrastructure Release Order Application capabilities at FCI Depots/District offices and

other Stakeholders Locations.

To study the external applications usage at Project Stakeholders to come up with the best possible Integration

solution.

To study the inflow and outflow operations at weighbridge at unit/shed.

Identify the problems and shortcomings of the current system.

To take valuable feedback and suggestions from the project stakeholders as part of Release Order Operations

Automation.

The main activities involved as part of the field study are

Face-to-face meeting with the stakeholders to understand the business process pertaining to Release Order

Operations and validate the information flow against the flow in the DPR to see any major deviations.

Classify/categorize the document and the information exchanged between other stakeholders part of the

business cycle.

Collect the physical copies involved business transactions regards to Release Order.

Find out the current IT infrastructure Release Order Application capabilities and working environment at Project

Stakeholder locations.

Details of the field survey reports and physical documents collected from the field are included in the ANNEXURE-C section of this document.



24

3.3 UNDERSTANDING THE EXISTING SYSTEM This section explains eCentric’s understanding about the existing system based on the Field Study.

3.3.1 PROJECT STAKEHOLDERS WITH ROLES & RESPONSIBILITIES

Department of

CS, F&PD

(GOI)

FCI (GOI)

Zonal office 1 Zonal Office 2 Zonal Office .. 5

Dept of CS, F&PD

(State - 2)

District Office 1 District Office 2 District Office .. N

Dept of CS, F&PD(State - 1)

Dept of CS, F&PD

(State ….. N)

Owned Depots 1---N Hired Depots 1...NCWCs 1 … N, SWCs 1 ----N

Regional Office 1 Regional Office 2 Regional Office ..N

District Office 1 District Office 2 District Office .. N

Stock Storage Points 1

Stock Storage Points 2

Stock Storage Points .. N

FPS 1 FPS 2 FPS ...N

Respective Central/State Govt.

Departments/ Agencies

FCI TPDS Schemes Other Welfare Schemes

Private Parties

OMMS & Others

Figure 2: Roles & Responsibilities

Release Order Operation

Department Users Roles and Responsibility

Release Order Initiation

Ministry of Consumer Affairs, Food and Public Distribution – GOI

Department Allocate of food grains for various Government schemes

Additional allocations on need basis

Allocations under OMSS and other schemes on need basis

FCI Department Issuing food grains under various schemes of the Govt. of India to the State Agencies/Parties

FCI Regional Office GM/AGM – Commercial Section

Receives State wise monthly allocations for the financial year from the Ministry

Send the district wise monthly allocation of food grains to FCI District offices.

FCI District Office Area Manager, To validate the payment made by



25



Manager, Commercial/Sales Section, Manager Accounts Section

State agency/Party against the requested food grains

To enter the Payment Details in the FAP

To issue the authorization letter to the Sales Section

To assign the active depot within the FCI District based on stocks availability

State Agency Department Heads To send the scheme wise monthly allocation requests to Regional office as per GOI allocation.

To release the payments to FCI District office for the allotted food grains

State Agency District Office/ Party

District Manager

To release the payment to FCI District office for the food allotted food grains

To assign authorized person to collect the Release Order and lift the commodities

Release Order Generation

FCI District Office Manager, Commercial/Sales Section

To generate the Release Order based on the request from the State Agency district officer/other parties

To send the Release Order to the assigned depot


Authorized person appointed by District Manager

To handover Indent Letter with payment details against the requested food grains in FCI District office

To Collect the Release order from the FCI District Office

Release Order Execution

FCI Regional Office Monitoring and Controlling of the overall Release Order operations of FCI district offices in the Region

FCI Depot Depot Manager, Depot In charge, Weigh bridge In charge

To assign the shed/block in the Depot and issue the delivery plan to State district office

To provide the Entry/Gate Pass to transport agency to lift the commodities against the Release Order

To issue the commodities against the Release Order to State Agency District Office/ Party

To weight the commodities at Weigh



26



bridge and 10% method

To entry the daily lifted quantities in Release Order as per Stock Issue/Dispatch Register

To update depot wise end of the day off take stock details in IRRS

State Agency District Office/Party

Authorized Representative/Transport Agency

Lifts the food grains against the Release Order based on the delivery plan issued by depot In-Charge through Transport Agency

Release Order Closing

FCI Depot Depot Manager, Depot In-Charge

Closes the Release Order once the State agency/party lifted all the commodities against the Release Order

To submit the Closed Release Order to FCI District Office

FCI District Office Manager, Commercial Section and Manager Accounts Section

To update the Release Order as closed in FAP and other applications

Release Order Extension


District Manager, State

Send Extension request with period along with reason against the Release Order to FCI District office

Receives the Approval or Rejection Letter from the FCI District Office

Payment of storage charges for the extension period (if applicable) by the State agency/party

To Lift the commodities within the extension period

FCI District Office Area Manager To send the extension request to FCI regional office

FCI Regional Office GM/AGM – Commercial Section

Approves/Rejects for the extension requests for first 15 days period

FCI Zonal Office GM/AGM – Commercial Section

Approves/Rejects for the extension requests beyond 15 days period

Release Order Cancellation


State Agency District Manager/ Party

Cancel Request send it to FCI District Office for un lifted quantity with reason

FCI District Office FCI Depot Office

Area Manager, Manager, Commercial Section and Manager Accounts Section Depot In-Charge

District office can cancel the Release Order by FCI District Office in two scenarios

a. The State agency/party is not lifted the quantity on time and extension request is rejected

b. Un availability of the Stocks in the



27



FCI designated Depots with in FCI district

Release Order Diversion



Diversion Request from the State Agency due to stocks un availability

Lift the stocks from the newly allotted Depot as per the Release Order

FCI District Office Manager, Commercial Section

FCI District office can divert Release Order to another Depot

1. Within the FCI District Office 2. Out of FCI District Office

a. Amount can transferred internally to newly assigned District office by FCI District office

b. Cancel the Release Order

Release Order Reimbursement



Reimbursement Request from the State Agency for un lifted quantity

FCI Depot/ District Office

Manager, Commercial Section and Manager Accounts Section

Cancel the Release Order

Reimburse the amount back to the State Agency/Party

3.3.2 SCHEMES Food Corporation India (FCI) releases food grains under various schemes to the State agencies/parties as per the guidelines given by the Department of CAF&PD. Following table explains the scheme wise allocation details with respective State agencies/parties responsible to lift the commodities. CA, F&PD department issues the allocation orders to food grains to following schemes

1. Welfare schemes 2. Commercial schemes

Following table explains the allocation and release of food grains with respect to State agencies/parties responsible to lift the commodities and is as follows. Scheme Name Frequency Purpose Orders issued to

Welfare Fixed Time intervals – Monthly/Quarterly/Half Yearly/Annual

To implement the subsidy Schemes by State Departments

Orders Issued to FCI head quarters and to State level scheme implementation departments

Welfare – Additional Need basis To serve the additional needs of the welfare schemes

Orders sent to the FCI head quarters and to State level scheme implementation



28

departments

Commercial Schemes - (OMSS (D) and others)

Need basis To release it to the third parties and private agencies to clear the excess stocks or to avoid the market fluctuations

Orders Issued to FCI head quarters to initiate the tendering process

Scheme Group Scheme Name Description

TPDS Schemes

AAY AAY A (Issues Against Pending Allotment of Previous Month)

APL Above Poverty Line (A-Issues Against Pending Allotment of Previous Month)

BPL Below Poverty Line Additional (A-Issues Against Pending Allotment of Previous Month)

Special Ad-hoc Allocation Special Ad-hoc Allocation

APL Additional(02-AUG-2010)

APL Additional (Allocation Date from 02-AUG-2010; changed from APL Additional vide FCI DO letter dated 11-JUL-2011)

BPL Additional (07-SEP-2010) BPL Additional

BPL Additional(06-JAN-2011) BPL Additional (Allocation Date from 06-JAN-2011 valid upto 30-JUN-2011)

BPL Additional(16-MAY-2011) BPL Additional (Allocation Date from 16-MAY-2011 valid upto 31-MAR-2012)

APL Additional(30-JUN-2011) APL Additional ((Allocation dated 30.06.2011 valid upto 31.03.2012) )

Allocation for 150 Districts(01-AUG-2011)

FCI letter no.1/7/2011-12/Sales dated 27 jul 2011;Additional monthly adhoc alloc under TPDS for 150 Poorest Districts in states of HP,UK,RJ,BR,JH,HR,JK,MR for the month of Aug to Oct 2011

Allocation for 174 Districts @ AAY rate (10-Oct-2011)

Allocation for 174 Poorest Districts for 1 year under AAY rate

Allocation for 174 Districts @ BPL rate (10-Oct-2011)

Allocation for 174 Poorest Districts for 1 year under BPL rate

APL Additional (12.03.2012) APL Additional (12.03.2012)

Additional Allocation for Poorest Districts @ BPL rate BPL Additional – Allocation date 07.05.2012

BPL Additional Allocation date 02.07.2012

BPL Additional Allocation date 02.07.2012 valid upto 31.03.2013

Additional Allocation for Poorest Districts @ AAY rate

Additional Allocation for Poorest Districts @ AAY rate’

APL Adhoc Additional (Allocation dated 22.05.2013)

APL Adhoc Additional (Allocation dated 22.05.2013)

NFSA National Food Security Act



29

BPL Additional (19.09.2013) BPL Additional (19.09.2013)

Other than NFSA Other than National Food Security Act, 2013 (NFSA)

BPL Addnl. Allocation Date 31.03.2014 BPL Addnl. Allocation Date 31.03.2014

APL Addnl. Allocation Date 31.03.2014 APL Addnl. Allocation Date 31.03.2014

BPL Addnl. Allocation Date 07.07.2014 BPL Addnl. Allocation Date 07.07.2014

APL Addnl. Allocation Date 07.07.2014 APL Addnl. Allocation Date 07.07.2014

APL Adnl. Allocation Date 09.04.2015 APL Adnl. Allocation Date 09.04.2015

BPL Adnl. Allocation Date 10.04.2015 BPL Adnl. Allocation Date 10.04.2015

OMSS (Domestic) Sale to State/UT Govt(Retail Sale)-From FCI OMSS(D)- (Agency Stock)

Sale to State/UT Govt(Retail Sale)-From State Agencies OMSS(D)- (Agency Stock)

Bulk Sale through Open Tender From FCI Depot NULL

Bulk Sale through Open Tender from State Agencies NULL

Small (Pvt) Traders upto 9 MT/Person/Depot/Day-From FCI Depot NULL

Small (Pvt) Traders upto 9 MT/Person/Depot/Day-From State Agencies NULL

Other Welfare Schemes (OWS) Annapurna

Annapurna A - (Issues against pending allotment of previous month)

Bhutan Bhutan

BSF / CRPF CRPF

ITBP ITBP

Defence Defence

EFP EFP

NPAG/SABLA NPAG A - (Issues against current financial years' allocation)

Relief Relief 1 - Flood

SC/ST/OBC HOSTEL SC/ST/OBC(HOSTELS) A - (Issues against current financial years' allocation)

Wheat Based Nutrition Programme WBNP A - (Issues against current financial years' allocation)

World Food Programme WFP 1 - (Domestic)

Welfare Inst. & Hostels Welfare Institute and Hostels A - (Issues against pending allotment of previous month)

UDS - Total UDS - Total

Indigent People Indigent People

Others Other Schemes

Mid Day Meal - Primary Standard MID DAY MEAL S(Primary Standard) A - (Issues against allotment of current month)



30

MSP 10 KG. MSP 10 KG.

Mid Day Meal - Upper Primary Standard

MID DAY MEAL S(Primary Upper) A - (Issues against allotment of current month)

NFFWP National Food for Work Programme A - (Issues against current financial years' allocation)

SGRY SGRY A - (Issues against current financial years' allocation)

Village Grain Bank Scheme Village Grain Bank Scheme A - (Issues against current annual plan)

Welfare Institutions Scheme - Addl. Allocation for CSR

Welfare Institutions Scheme - Addl. Allocation for CSR

Miscellaneous Sample for a Scheme Issue Samples for Schemes

Sale of Non-Issuable Stocks Tender Sale of Non-Issuable Stocks

Additional Allocation

Special Alloc.@ 8.45/11.45 per Kg.(06-JAN-2011) Special Allocation @ 8.45/11.45 per Kg.

Additional - @ Economic Cost Additional 1 - @ Economic Cost

Additional @ MSP Derived Rate Additional @ MSP

Additional @ Open Sale Rate Additional @ APL Rate Additional @ BPL Rate Additional @ Free of Cost Export Export Tender Sale (Sound)

excl. OMSS (D) Tender Sale(Sound) Excluding OMSS (Domestic)

Tender Sale - D category with TE opened for current date

Food Corporation India (FCI) maintains the food grain stocks at the depots and releases it to the State agencies/parties based on allocation guidelines given by the Department of CAF&PD. Following table explains the allocation and release of food grains with respect to State agencies/parties responsible to lift the commodities and is as follows. Active Schemes

Scheme Name Responsible Commodities Regular /Need basis

Lifting Duration

Payment made /Lifted Agency

TPDS (Targeted Public Distribution System) APL,BPL and AAY, NFSA & Other than NFSA Schemes

State Department of Consumer Affairs &Public Distribution

Rice & Wheat Regular Monthly 30 days or as per GOI order

District Office - CSC - Pre Payment



31


Lifting Duration


TPDS (Additional Allocations for APL,BPL and AAY, NFSA & Other than NFSA Schemes

State Department of Consumer Affairs &Public Distribution

Rice & Wheat Need basis

As per the GOI order

District Office - CSC - Pre Payment

MID-DAY-MEAL (National Program of Nutrition Support to Primary Education)

State Department of Consumer Affairs & Public Distribution

Rice & Wheat Regular Quarterly – 115 days

Department of School Education & Literacy- MoHRD – Credit Basis

Welfare Institutions and Hostels

State Department of Consumer Affairs & Public Distribution

Rice & Wheat Regular Monthly

Wheat/Rice Based Nutrition Program

Dept. of Child and Woman Development

Rice & Wheat Regular Quarterly – 115 days

Dept. of Child and Woman Development – Pre Payment

SC/ST/OBC Hostels & Welfare Institutions

State Department of Consumer Affairs & Public Distribution and

Rice & Wheat Regular Monthly - 50 Days or as per GOI order

Ministry of Social Justice & Empowerment – Pre Payment

Rajiv Gandhi Programme for Empowerment of Adolescent Girls- “AGPLM/NPAG/SABLA”

State run Women Welfare

Rice & Wheat Regular Quarterly – As per GOI Order

Defense Services State Defense Accounts Department

Rice & Wheat Regular Quarterly - 225 Days

State Defense Accounts Department - Pre booked stocks after prior inspection and quality check. Same stocks will be issued

Para Military Forces (CRPF/BSF/ITBP)

CRPF/BSF/ITBP Stations

Rice & Wheat Regular Monthly/Quarterly - 50 Days

CRPF/BSF/ITBP Stations



32


Lifting Duration


OMSS (D) - Open Market Sale Scheme – Retail Parties – Retail Traders Bulk Sale – Wholesalers

Private Agencies/Parties

Rice & Wheat Need basis

As per DO, FCI or Release Order

Sale it ether open market price or prices fixed as per bidding

Annapurna State Department of Consumer Affairs &Public Distribution

Rice & Wheat Regular Monthly - 50 Days or as per GOI Order

Discontinued/ Allotment Letter Not Received Schemes:


Lifting Duration


SGRY - Sampoorn Gramin Rozgar Yojna

State Department of Rural Development

Rice & Wheat Regular Monthly - 50 Days

District Project Director – Pre Payment

Emergency Feeding Program

Ministry of Social, Justice and Empowerment


Ministry of Social, Justice and Empowerment - Pre Payment

Village Grain Bank Scheme

Ministry of Tribal Affairs


Ministry of Tribal Affairs - Pre Payment

World Food Program

Exported to other Countries on need basis

Rice & Wheat On Need basis

To clear the Surplus Stocks

N/A

NFFWP - National Food for Work Program

State Department of Rural Development


District Project Director – Pre Payment

3.3.3 RELEASE ORDER STEPS



33

The following are the Release Order business processes details with suggested approach based on the Field Study at the Stakeholder premises is given in the tabular form below:

Process Steps Process Observation Suggested Approach Release Order Operations

All operations use manual process and managed through Registers and booklets. communication between stakeholders through physical forms and manual transfer

Release Order Initiation

Manual – Monthly once. Scheme wise Commodity Requests from the State Agency/ Department Payment is made to the FCI District Office based on CIP. Indent will be generated with bank and requested commodity Details

Monthly once and there is no online verification and validation of Central allocations against the Requested quantity.

The proposed application shall capture the monthly allocation parameters online (FEAST or proposed Central App)/offline along with Central Issue Price of the food grains. This can be made available to the State Agency/Party to generate the Indent. Alternatively the monthly allocation details created by the FCI Regional office shall be used to validate the allocations fed by the State Agency/Party during online Indent Submission.


Manual – Generated at FCI District Office by Sales Section based on Indent and Payment Confirmation Certificate from FCI Accounts Section.

Monthly once and can be generated on any day after the payment received and verified by FCI district Account section.

The proposed application shall verify the

confirmation of Payment

from FAP

stocks availability with IRRS

applications

and generate the Release

Order with the digital

signature


Manual – Entering the off take details daily at Depot by Depot In-Charge based on weighbridge Release Order Application Capturing weight and lifted quantity.

The current IRRS application captures daily end of the day depot wise inflow and outflow details. Off-take is captured against the individual Release Orders.

To capture the inflow and outflow stocks against individual the Release Order by integrating with weighbridge system for capturing the weighment data.

Release Order Closing Manual – Depot In charge closes the Release Order by crossing on the physical copy written between the two crossed lines as “Completed/Killed”.

Depot In-Charge closes the Release Order once the State agency lifted the entire quantity and send to District Office for Reconciliation.

The status can be updated in Release Order Application and same can be automatically reflected in all other dependent applications using external data sync interfaces.

Release Order Manual - Release Order is Manual Process. FCI Application should provide a



34

Process Steps Process Observation Suggested Approach

Diversion diverted to another Depot if un availability of stocks at assigned depot.

District officer write the newly assigned Depot Name in the existing Release Order

provision to assign the alternative depot within the FCI District and Release Order shall be updated accordingly.


Manual - Reimbursement Amount for the un-lifted quantity will be calculated manually and Reimburse back to the State Agency/Party.

Manually calculating the amount and record the reimbursement amount in the FAP and Release Order is closed by the FCI District Officer.

System should automatically calculate un-lifted quantity and status shall be maintained. The Release Order shall be closed once RO receives the reimbursement payment confirmation from FAP.


Manual – To lift the quantity beyond the valid up to date.

Manual – 15 days – Approving authority is FCI Regional Office > 15 days – Approving authority is FCI Zonal Office > 30 - Ministry of F&PD

System shall facilitate the Regional/Zonal Office to approve/Reject the Release Order Extension Request through RO application.

3.3.4 RELEASE ORDER PARAMETERS

Release Order Parameters

Process Observation Suggested Approach

Generation Manual – Release Order will be generated Scheme & Commodity and allots designated depot based on the stocks availability and requested location by State Agency

Any date after Indent received.

Release Order should be generated within the time frame fixed by FCI.

Frequency Monthly - Release Order will be generated monthly once as per the Request

Monthly As per indent by State Govt.

Valid up to Date 7/14 Days – Time period to lift the commodities by State agency once the Release order is generated

7/14 Days in normal Scenario. In case of Extension - with in Extension period (Scheme Dependent)

The validity period should be calculated automatically by system as per the scheme.

Number of Copies 4 Copies 1. Original –to Depot 2. Duplicate – send it to State Agency/Party 3. Triplicate - to Depot – Back to District office 4. quadruplicate – Copy retained in the Booklet

4 Copies – Colors are not uniform at all the places

4 Copies with Digital Signature



35

Format Follows FCI Standard format with below details Release Order No. : Serial Number of the booklet Quantity Bank Payment Details Depot Details Daily Off-take Details

Booklet Running Sequence Number as a Releaser Order number

Unique Release Order format throughout the country.

Payment Mode RTGS Payment can made to FCI District Office account by State Agency on Monthly basis as per the Indent

RTGS/DD RTGS/DD

Crop Year FIFO Stocks will be allocated based on the FIFO based on the Age

Generally lift the stocks in FIFO. Sometimes it may relaxed due to surplus stored non open area/ alleyways due to lack of space in the block/unit

To lift the quantities based on the FIFO and Crop Year

Transport Agency Users Hired/Owned Transport Agency to lift the Commodities

Lift the commodities as per the Release Order based on Delivery Plan/Issue planning sheet

N/A

Weigh bridge Weighbridges of various makes and manual entry details provided by unit-in-charge and auto generated weighment data

Uses different makes and modals

Capturing of weighment data generated by Weighbridge software

Communication Phone/Mail/Physical Copy/Person

Phone/Person/Physical Copy

e-Mail/SMS

Stock Reconciliation at Depot

Manual – Daily Once Based on M-form Capturing of weighment data generated by Weighbridge software

Execution Based on physical copy Release Order Application Capturing the daily off-take as per Register/form

Execution process Status should be made available online

Closing Manual - After lifting the entire commodities for the respective Release Order

Only day wise lifted quantity is recorded

Should be updated in the Release Order as well as all other external applications automatically

Weigh bridge To capture the weighment data

Separate field to capture the Release Order Number is not available. Using some

Should provide the weighment details based on the Release Order number in the format specified by



36

other field for entering the Release Order number

Release Order application

3.3.5 EXTERNAL APPLICATIONS

External Applications Process Observation Suggested Approach

Weighbridge – Depot Release Order Application Capturing weighbridge data along with Release Order by entering in the other un used field

No online integration Weighbridge vendors should provide the Integration component to access the weighment data from weighbridge system

FAP – Used at District Office

On Need basis – Used by FCI District office Accounts Section to enter the Bank and payment details against the Release Order

Used by District office on need basis to Release Order Application Capturing the bank and payment details irrespective of the Release Order Verify the payment details through Online Bank Account

Release order application can provide the Indent data to FAP so that FAP shall take care necessary verification and validation and provide confirmation to Release Order application

IRRS On Need Basis – used by FCI District office/Depot to update the end of the day off-take stock positions

Manual Entry RO shall capture the inflow and outflow stocks against individual the Release Order by integrating with weighbridge system for capturing the weighment data and can be used by IRRS

DCMS On Need Basis – Not Using as part of assigning the Depot

Using on Need basis Release Order should Capture the designated depot data to create the Release Order

WINGs To automatic Depot Operations w.r.t. stock management

Automated all the stock management operations of the depot including the weighbridge Integration

To provide Release Order details to WINGs

NCDEX Release Order FCI is utilizing the NCDEX platform to generate Release Orders for issues against the OMSS(D)

It helps to generate the Release Order based on the bidding by the parties. All other Release Order Operations will done manually

Enter the required parameters into Release Order application to perform the next operations



37

Following external applications are used by Project Stakeholders to perform the Release Order operations. All the external applications are working independently.

Application Name

Description Used by Used in Purpose

DCMS - (Depot Code Management System)

DCMS maintains the repository of the FCI Depots. It facilitates the project stakeholders in adding new Depots and hiring/de-hiring of the Depots.

FCI District Office –Sales Section


To identify the active/designated depots available within the FCI District jurisdiction

IRRS - IISFM

Rapid Reporting

Services

IRRS application maintains the depot wise end-of-day stock positions along with daily inflow and outflow quantities of various food grains crop year wise.

FCI District Office –Sales Section


To know online stock positions in the designated/ alternate depots

FAP – Financial Accounting Package

Financial Accounting Package

(FAP) is being used to record

and maintain FCI’s financial

transactions.

FCI District Office –Accounts Section

To create the Release Order

To maintain uniform supplier/party details To receive the payment confirmation for deposited amount for Release Order Creation

FEAST - Food and Essential Commodities Assurance & Security Target

FEAST is used to monitor the supply chain of the PDS for the commodities lifted from FCI Depots

FCI District Office –Accounts Section FCI Depot In-Charge State Agency/Party Official

Release Order Initiation & Release Order Execution

To capture the allocation demand requests for TPDS schemes Stock Reconciliation at FCI Depot and State Agency Depot

SIMS – Stakeholder Identity Management System

SIMS holds the masters of State Agency stake holder’s details, who are involved in the PDS operations.

FCI District Office –Accounts Section FCI Depot In-Charge State Agency/Party Official


To get the State Agency details for TPDS schemes

Weighbridge Weigh bridges yield an automated and authenticated weighment data for the incoming and outgoing commodities at any given depot

FCI Depot In-Charge


To capture the commodity weighment data passing through weighbridge

NCDEX Release Order

To generate the Release Order online for OMSS schemes

FCI District Office –Accounts Section


To perform the Release Order Execution steps



38

3.4 APPLICATION PROSPECTIVE

Release Order is an authorized document generated by Sales Department of FCI district office on the payment made by the respective State parties like State agencies and other private agencies. It facilitates the respective State Agencies /Parties to lift the commodity from FCI depots.

3.4.1 RELEASE ORDER PROCESS STEPS

Release Order operations are broadly categorized into following 5 process steps based on the functionality.

1. Release Order Initiation

a. Scheme wise food grains allocation details.

b. Indent generation based on Central Issue Price

2. Release Order Generation

a. Designated depot assignment

3. Release Order Execution

a. update the lifted weights and quantities against the Release Order by integrating with

Weighbridge

4. Release Order Closing

a. Close the Release Order once the State Agency/Party lifted all the commodities against the

Release Order

5. Other Processes

a. Release Order Extension – Not lifted the commodities within the Release Order validity period

b. Release Order Diversion – Diverted to other Depot due to stocks unavailability

c. Reimbursement – Reimbursement of pending amount to State Agencies/Parties for un lifted

quantity.

d. Release Order Cancellation – Cancel the Release Order in case of not lifted the quantity in-time

and is not extended

6. To integrate the Release Order application with External Applications

a. DCMS

b. IRRS

c. FAP

d. FEAST

e. Weigh bridge

f. NCDEX Release Order Application

The consolidated process flow diagram is given below for Release Order operational steps



39

Prepares the District

wise food grain

requirements sheet

based on GOI

allocations

Prepare the district

wise indent letters

for each scheme

Send the indent to

the accounts

section for payment

Receives the Indent

letter with payment

details from the

State agency/party

District Office

FCI District Office Generate

4 Copies of the RO and

handover it to assigned

Depot and State Agency

District Officiall/ Party

FCI Depot In charge

generate the Issue

planning sheet and

handover it to State

Agency/party

State Agency/Party

Lifts the Commodity

Depot based on

Planning sheet using

Transport Agency

Allocated

Commodity

Lifted to

Truck

Weight the empty truck and

then loaded truck. Capture

the Weight and Quantity.

Transport Agency submit

the Gate Pass at Gate

RO Close once all

the food grains

lifted from the

Depot against RO

RO INITIATION STEPS

(Pre Process)

RO PROCESS STEPS

(Generation, Execution & Closing)

Extension Request

by State Agency

with No Days (15,30

or More

Approved

???NO (Rejected)

YES

Lift the Stock with in the

Extension period

No

No Stock

Certificate issue

by Depot

manager

District Office

diverts the RO to

another depot

based on Stocks

Availability

State Agency

Submits the

Reimbursement

Request

RO Closes and

release the pending

amount back to

State Agency/Party

State Agency/Party State Agency/Party

FCI District OfficeFCI District Office


FCI Depot – Incharge/Stage Agency/PartyFCI Depot – Incharge/Stage Agency/PartyWeighbridge Incharge

Weighbridge InchargeFCI Depot

FCI Depot

FCI DepotFCI Depot

State Agency/PartyState Agency/Party

YES

FCI Regional / Zonal OfficeFCI Regional / Zonal Office

START

END



RO EXTENSION PROCESS

(RO Expires)

RO DIVERSION PROCESS

( stock Not Available )

RO REMERSEMENT PROCESS

(Un Lifted Quantity)

Account Section/Party

Transfer the amount to

FCI District Office either

through RTGS/DD

Verify and assigns

the Depot based on

the Stocks availability

Figure 3: RO Process Steps

3.4.2 RELEASE ORDER INITIATION The Release Order Initiation process includes the following steps:

3.4.2.1 ALLOCATION PROCESS

Department of Consumer Affairs, Food & Public Distribution (CA,F&PD) of Government of India (GOI) receives the

food grain requirements from the State food departments to implement the welfare schemes.

CA,F&PD department of GOI issues food grains allocation orders under various schemes as per the allocation

guidelines and policies.

The schemes are broadly classified into two types:

1. TPDS & other welfare schemes

2. Commercial schemes



40

Following are the steps involved in the allocation process based on the schemes:

a. TPDS & Welfare Schemes – Fixed time intervals

1. State Departments sends the scheme wise commodity requirements to the Consumer Affairs, Food &

Public Distribution (CA, F&PD) Department, GOI along with previous utilization/un-lifted quantity details

against previous allocations.

2. CA,F&PDS verify the requirements and allocates the commodities to the States, based on the guidelines

and issues the allocation order to the FCI head office and respective Central/State Departments.

3. FCI HQ sends Letters to the Respective Zonal/Regional offices to make sure the allotted quantities are

available in the designated FCI Depots.

4. A state food department segregates the State level allocations across revenue districts and sends the

same to FCI Regional office.

5. FCI regional office sends the revenue district-wise and scheme wise allocation of food grains details to

the FCI district office.

6. Area Manager of respective FCI District Office ensures that the food grain is available in the designated

depots for lifting by the State Food Dept. / Agencies.



41

Allocation process – Welfare Schemes

FCI Head/Regional/

District Office

Consumer Affairs, Food

& Public Distribution,

GOI

Requesting Department

– State/ Central

Start

Prepare the scheme

wise food grain

requirements

Prepare the revenue

district wise allocations

and send it to FCI

Regional office

CA,,F&PD verifies the

requirements and allocate

the commodities to the

states with allocation

guidelines

END

Send the allocation Orders

to the FCI head office and

State Departments

FCI Head Office sends the

Letters to the FCI Zonal/

Regional Offices

Prepare the scheme

wise demand Requests

FCI District Area Manager

maintains the stocks at

designated depots as per

the allocations

FCI Regional Office

validate against GOI

allocations

FCI Regional Office sends

the allocation details to

FCI districts offices

Figure 4: Allocation Process - Welfare Schemes

b. Commercial Schemes - Open Market Sale Scheme – OMSS - On need basis To clear the surplus stocks, FCI releases food grains into open market via OMSS (D) scheme and sells it to the private agencies/parties based on the guidelines given by the Ministry of CA,F&PD to clear the surplus stocks from the Depots. This can be done at any time usually in following scenarios

1. To avoid the financial burden of storage and maintenance of food grains 2. To maintain the storage space for next procurement season 3. To stabilize the prices in the open market and inflation



42

Allocation Steps 1. Ministry of CA,F&PD decides the allocation of various commodities under OMSS scheme.

2. FCI Zonal/Regional office forms a committee to finalize the tender guidelines and eligibility criteria as

per the guidelines specified by CA,F&PD

a. Eligibility Criteria

b. Methodology

c. Payment Terms and Conditions

d. Minimum Quantity and Issue Prices etc.,

e. Empanelled State/private parties or all

3. Lifting priority

a. Stock kept in unscientific plinths

b. Stocks kept in CAP

c. Stocks kept in covered godowns

d. Non-rail head godowns

e. Godowns connected to railway goods shed (railheads).

4. Ministry of CA,F&PD publish tenders through online portal (NCDEX or any other portal)

5. Evaluate the submitted bids

6. Select the eligible parties

7. Assign the depots and Issue the allocation orders to the bidding parties



43

Allocation process – Commercial Schemes

FCI Head/Regional

Office

Consumer Affairs, Food

& Public Distribution

GOI

FCI District/Regional

Office

Send the allocation letters

to the FCI Head Quarter

Allot the quantities to sell

the commodities to the

private parties/agencies

by keeping the buffer

stocks of 3 months for

welfare schemes

END

Regional office select the

bidders by calling the

tenders

FCI Head Office sends the

allocation Orders and

guidelines to the FCI

Zonal/Regional Offices

Issue allocation letters to

successful bidders

Start

Prepare the surplus

Stocks availability

Submit to the Govt. of

India

Figure 5: Allocation Process - Commercial Schemes

3.4.2.2 INDENT GENERATION

1. State Agency/Party calculates the Deposit amount as per the central issue price for the allotted

commodities.

2. State Agency/Party makes the payment to FCI’s Bank Account through DD/RTGS/NEFT or any other financial

instrument recognized by FCI.

3. State Agency/Party prepares the indent letter with commodity (scheme name, required quantity etc.) and

payment (amount, bank, UTN number) details.

4. Submits indent to the FCI district office to initiate the Release Order Creation process.



44

Indent Generation

State Agency/Party

Validate the demand vs

allocations

Submit the indent letter

to FCI District office for

issuing Release Order

Release Order

Generation

END

Deposit the amount to

FCI District office

account based for the

required /allotted

quantity

Prepare the Indent

Letter by providing

required commodities

with payment details

START

Figure 6: Indent Generation

3.4.3 RELEASE ORDER GENERATION STEPS Releaser Order generation process at FCI District Office consist of the following steps.

1. FCI district commercial section receives the Indent Letter along with payment or payment details from the

State Agency/Party.

2. FCI district commercial section send to accounts section for payment amount verification.

3. Accounts section verifies the deposit amount and enters the payment details in the FAP.

4. Accounts section sends the authorization letter to sales / commercial section.

5. Sales/ commercial section checks the stocks in the active depots using DCMS and IRRS respectively and

assigns the depot for stock lifting.



45

6. FCI commercial section creates the Release Order and submits to FCI district’s area manager for approval.

7. FCI district’s Area manager approves the Release Order

8. FCI commercial section generates 4 copies of the Release Order and sends it to State Agency/Party and

Depot.

RO – Generation Process

FCI District Office

(Accounts Section)

FCI District Office

(Sales Section)State Agency/Party

Checks the Active

Depots and stocks

availability

Receives the Indent letter

from the State agency/

party and submit to the

department

Start

Sends the Indent Letter

with payment details to

the Account Section

RO Initiation

DCMS/IRRS

Verified OK?

Enter the payment

details to FAP.

Send authorization

;letter to Sales

Department

Yes

Release

Orde

Date

Quantityr

Release

Orde

Date

Quantityr

Release

Orde

Date

Quantityr

Release

Orde

Date

Quantityr

Retained in booklet

Send it to State Agency/Party

Send it to Depot to fill the daily lifted quantity

Send to Depot Return back to FCI District Office after closed

END

RO ExecutionCollects the Release

Order from FCI District

Office

Generate 4

Copies of Release

Order

FAP

Receives the Indent

Letter with payment and

commodity details

NoReject the Indent

and send back to

State Agency/Party

Verity the

payment Online through

Bank Portal

Figure 7: RO Generation Process



46

3.4.4 RELEASE ORDER EXECUTION STEPS Releaser Order Execution process includes following steps:

1. State Agency/Party visits the depot with Release Order.

2. Depot In-charge prepares the delivery plan and handover it to State agency/party.

3. Transport agency brings truck to the depot and produces the release order/delivery plan.

4. Gate in-charge issues the Inward gate pass to truck driver.

5. The truck driver positions the truck onto weighbridge.

6. Weighbridge software provides the weight of the empty truck.

7. Weighbridge Operator enter the following details:

a. Inward gate pass number

b. Truck number

c. Release Order number

8. Unit In-charge loads desired quantity onto truck and fills details in Weight Check Memo (WCM).

9. Truck driver positions his truck at weighbridge and shows WCM & initial inward receipt.

10. Weighbridge operator fills serial number and details of commodity, bag types, unit number, stack number,

provided by Unit-in-charge & weight of one bag into system. System also captures tare weight of truck and

calculates net weight of issued quantity. Revised receipt gets generated and given to truck driver.

11. Truck goes back to unit and shows weighbridge receipt.

12. Unit In-charge takes back extra loose grain or issues balance loose grain depending on excess or short of

issued quantity using beam scale.

13. Truck is again weighed and weighment slip is generated automatically by the weighbridge.

14. Once it is ensured that issued quantity is less than or equal to allocated quantity, details are entered into

WCM and M-form.

15. Unit In-charge generates four copies of gate pass and gives one copy to truck driver.

16. Truck driver deposits outward gate pass at exit gate.

Repeat the Steps 1 to 16 till all the assigned quantity against the Release Order is lifted.

17. The Daily Stocks Issue Register is updated for the stocks lifted against the Release Order

18. Weighbridge operator generates daily off take/ dispatch report against the Release Order and sends it to

depot manager.

19. Release Order gets killed/closed by Depot Manager once entire against the release order gets lifted.



47

RO – Execution Process

State Agency/Party/

Transport Agency

FCI Depot

(Depot Incharge)Weighbridge In- charge

Transport Agency brings

the trucks to Depot Gate

and shows the RO and

Delivery plan

Weigh bridge operator

weighing the tare weight

of the empty truck

State Agency Official/

Party Collects the

Delivery plan from Depot

In-Charge and lift the

commodities accordingly

Prepares the Delivery

plan

Unit In-charge loads

the desired quantity

and fills the details in

the Weight Check

Memo

Weighbridge operator

fills truck and transport

agency details including

truck number into

weighbridge software

gives inward receipt to

Truck Driver

Start

State Agency Official/

Party visit the Depot with

Release Order Weighbridge operator fills

serial number and details

of commodity, bag

types & weight of one

bag to get the net weight

of the Commodity

1

3

4

Based on the weigh

bridge Receipt Unit In-

charge takes back extra

loose grain or issues

balance loose grain

depending on excess or

short of issued quantity.

5

Depot In-Charge

Accumulate daily off-

take quantity of the

Depot enter into IRRS

and enter the lifted

quantity against RO

6

8

RO Closing

Repeat the Steps 1 to 8 and lifted Quantity against RO will be

updated in the RO application either offline/ or by weighbridge

integration. Till all the quality lifted against the Release Order Yes No

Food grains are

not lifted with in

the Validity Period

RO

Extension

Stocks are not

available in

assigned Depot

RO

Diversion

No

END

END

RO

Generatio

n

IRRS

END

Gate In charge verifies

and permit the truck to

lift the commodities

2

7

Figure 8: RO Execution Process

3.4.5 RELEASE ORDER DIVERSION STEPS

Either in case of stock unavailability or in case such conditions where in stock can’t be lifted from designated depot, Commercial section of FCI District office diverts the Release Order to any feasible depot within same FCI district. In case Release Order needs to be diverted to any depot beyond the FCI district, Regional office authorizes the Release Order diversion to any depot of other district.

1. Depot Manager of the initially identified depot certifies that there is no stock to issue against the Release

Order.

2. FCI District Office diverts the Release Order to another depot within the same FCI District.

3. Party lifts commodity from the depot identified later.



48

Release Order – Diversion Process

FCI District OfficeCSC District Office

Release Order

Diversion

Release Order

Closed

Release Order

Generation

Yes

FCI District office can

divert the Release Order

to another depot due to

unavailability of stocks in

the assigned depot

Same FCI

District

Start

FCI District office

divert the Release

Order to another

Depot based on

stocks availability

Release Order

Execution

New Release Order

is generated by the

newly assigned

District Office

Current Release Order

is closed and district

office will transfer the

amount to the newly

assigned District office

No

END

Figure 9: RO Diversion Process

3.4.6 RELEASE ORDER EXTENSION STEPS If Depot Manager receives requisition for lifting beyond the validity date (usually after 7 working days) of Release Order then concerned agency is denied for stock lifting. In such scenario, agency sends extension letter to FCI office. Following are the steps to execute Release Order extension request for TPDS and welfare Schemes:

1. Depot Manager receives Day wise requisition from State Agency / Party

2. FCI district office will extend the RO up to the validity period given by GOI.

3. After the expiry of validity period given by GOI, Regional Office can extend the RO up to 15 days and

thereafter, Zonal Office can extend it for another 15 days.

4. Ministry can extend the RO for no limit.

5. Extension request gets approved / rejected.

Following are the steps to execute Release Order extension request for OMSS (D) Scheme

1. Depot Manager receives Day wise requisition from State Agency / Party.

2. Extension Request as provided in the guidelines in vogue of OMSS (D).

3. Extension request is approved / rejected.



49

Release Order – Extension Steps

CSC District Office FCI District OfficeFCI Regional/Zonal

Office

Release Order Execution Release Order

Execution

Yes

No

Approve

Reject

Approve


State Agency/Party requests for Release

Order extension to FCI District Office with

Reason for not lifting the food grains in time

Send the Request to FCI Regional for Release

Order Extension

Send it to Ministry for Approval

If Days is <= 7

END

Regional

Office Can Approve

or Reject


Ministry Can

Approve/Reject

If Days is <= 15


Start

Yes

No

District Office Can

Approve or Reject

Approve

Reject

Reject

Figure 10: RO Extension Steps



50

3.4.7 RELEASE ORDER REIMBURSEMENT STEPS

If Extension request of State Agency/Party is rejected by FCI office then State Agency submits reimbursement request to get the reimbursement against un-lifted quantity. State Agency may also submit reimbursement request if they are not willing to lift the commodity allocated to them.

In such scenario, following steps are recommended for executing the reimbursement request.

1. State Agency / Party submits reimbursement request.

2. Account Section receives reimbursement request.

3. Get off-take details against Release Order.

4. Calculate payment for remaining quantity.

5. Closing of Release Order.



51

3.4.8 RELEASE ORDER OPERATIONS AT DELHI In Delhi, the Release Order Generation and Execution process is different from the other States. The stocks can be directly lifted to the Fair Price Shops and Single Release Order can be generated irrespective of the scheme and Commodity. Following are the operations steps involved for Release Order

3.4.8.1 BULK PARTIES

Figure 11: Bulk Parties



52

3.4.8.2 SMALL TRADERS

Figure 12: Small Traders



53

3.4.8.3 KENDRIYA BHANDAR

Figure 13: Kendriya Bhandar



54

4. PROPOSED BUSINESS SOLUTION This section presents high-level overview of the proposed System and the environment in which it will be used, the anticipated users of the software, known constraints, assumptions and dependencies.

4.1 RELEASE ORDER ARCHITECTURE The following are the key components which are proposed to be in-built the proposed Release Order Application.

1. Workflow engine - Core business component which includes the functionality to automate all the release

order operations from release order initiation to closing.

2. Centralized intelligent data exchange engine - Links the external applications. To develop the data communication interfaces between the Release Order Applications with external applications.

3. Web Portal - Online reporting and application dashboard which allows stakeholders to perform the Release Order tasks remotely. It allows the users to track and monitor the Release Order status online.

4. Centralized database - Data store for Release Order Application, to generate the reports online.

Following is the Release Order Application architecture with the Components.



55

RO Database

Mail Server

SMS Server

DCMS/IRRS

FEAST/SIMS

Weighbridge

FAP

Allocation Indent Generation

RO Generation RO Execution RO Closing

RO Extension RO Diversion RO Reimbursement

WORLFLOW MODULE

DATA EXCHANGE MODULE

SMS Interfaces Mail Interfaces

DCMS Interfaces IRRS Interfaces FEAST Interfaces

FAP Interfaces

FCI District & Depot

Officers

FCI HQ/ Zonal/

Regional Officers

State Agencies /

Parties

WEB PORTAL

User Access

ManagementWorkflow Managment

Reporting

Engine

Security

Managment

Administration &

Configuration

HTTP

GU

I

I

NT

ER

FA

CE

S

DA

TA

E

XC

HA

NG

E

IN

TE

RF

AC

ES

CONNECTIVITY INTERFACES

CONNECTIVITY INTERFACES

ADO .NET

END USERSRELEASE ORDER APPLICATION EXTERNAL APPS

SMS

API

MAIL

API

DB

Scripts

DB

Scripts

CSV

/XML

/Open Data

CSV

/XML

/Open

Data

Figure 14: Architecture

4.2 FUNCTIONAL REQUIREMENTS This section explains the module wise high level functional requirements of the proposed Release Order Application

4.2.1 WORKFLOW ENGINE The workflow engine module is responsible for implementing the business functionality to automate the Release Order operations from initiation stage to the Closing including the exceptional Release order processes like Release Order Extension, Diversion, Cancellation and Reimbursement based on Scheme and commodities. Following are the identified functional requirements to implement the Release Order Workflow Engine:



56

4.2.1.1 ALLOCATION

Department of Consumer Affairs, Food & Public Distribution (CA,F&PD). GOI allocates commodities to the State and State allocates to their revenue districts under various schemes and issues the allocation letters to Food Corporation India based on the prescribed guidelines and utilization along with unutilized allocation reports. FCI will releases the food grains to State agencies /parties under various schemes as per the allocation guidelines prescribed by Department of CA, F&PD. Release Order application should capture the scheme wise allocation details based on the allocation guidelines. Following are the functional requirements for the allocation process Requirement #1: Ability to add the scheme wise allocation details based on the central allocations for the new schemes.

o State wise

o Revenue District wise

To address this requirement RO application would offer a module called Allocation which further be divided in 2 sub module as follows 1. State allocation

2. Revenue District Allocation

State Allocation: Only authorized users having access State Wise or Revenue District Wise module would log in the application and add the scheme wise State or Revenue District wise allocation. In State Wise Allocation module, user would be provided with below details:

State

Allocation Duration (From and To)

GOI Allocation Order No.

GOI Order Date

Scheme Group

Scheme

Commodity Details

Commodity

Allocation Type

Quantity (MT up to 3 decimal places)

GOI Allocation Order Validity

Allocation letter for reference



57

User would key-in/select the appropriate values against aforementioned fields to create state Allocations. Business Rules and Validations: 1. Allocation would be done only for one state at a time

2. Allocation Duration (From and To) would be mandatory field for user. Allocation from date should be

less than or equal to Allocation To date.

3. GOI Order Date would be a mandatory field for user. GOI Order Date should be less than Allocation to

Date.

4. Scheme Group and Scheme Name would be a mandatory field. Based on the selection of “Scheme

Group”, scheme name dropdown should be populated with the appropriate values. Scheme Name

dropdown should only show those schemes which would be mapped to the respective Scheme groups

5. Multiple Commodity Details can be added in one State Allocation.

6. Commodity Name would be a mandatory field.

7. Allocation Type would also be a mandatory field having the values as: “Regular/Additional/ Ad hoc”.

8. GOI Allocation Order Validity date field would be mandatory and greater than GOI Order date

Revenue District Wise Allocation: In Revenue District Wise Allocation module, user would be provided with below details to fill:

State

GOI Allocation Orders Dated between (From and To)


Select State Allocation Year & Month

State Allocation Order No.

Allocation Order Date

Scheme Group

Select Scheme

Commodities Details

Revenue District**

Commodities

Total State Allocation

Payment Cutoff Date

Enter Allocation (MT up to 3 decimal places)


User would key-in/select the appropriate values against aforementioned fields to create revenue District allocations. ** Note: (1) One Revenue District is being served by more than One FCI District. VC is proposed against the same

example Durgapur and Burdwan in West Bengal Region.



58

(2) Provisioning for sub division allocation.

Business Rules and Validations: 1. Allocation would be done for one state at a time

2. GOI Allocation orders Dated between (From and To) would be mandatory for user. GOI Allocation from

date should be less than or equal to GOI Allocation To date.

3. GOI Allocation Order No. field would populate only those orders falling between the GOI Allocation

orders from and To Date selected.

4. Based on the GOI Allocation order No. selection, Scheme group as well as scheme name dropdown

would only show the mapped appropriate values .

5. Special character would be restricted in Allocation Order No. except ‘/’ and ‘-‘.

6. Based on the GOI Order No., Commodity field would only show the mapped appropriate values

7. Revenue District field would be mandatory and populate the values based on State selected by the user

8. Allocation should also be done in multiple revenue districts.

9. The total Quantity should be less than or equal to the total Quantity of the state allocation

Requirement #2: Ability to update scheme wise allocation details based on the central allocations for the existing schemes.

o State wise

o Revenue District wise

Solution: State Wise Allocation: To update State Wise Allocation details, user would modify the below fields:

State

Allocation Duration (From and To)


GOI Order Date

Scheme Group

Scheme

Based on updating above fields, user would modify below commodity related details: Commodity Details

Commodity

Allocation Type

Quantity (MT up to 3 decimal places)

GOI Allocation Order Validity


Business Rules and Validations: 1. User can edit allocations and excess off take if any will be flagged in case allocation has been reduced.

2. Allocation Duration (From and To) would be mandatory field for user. Allocation from date should be

less than or equal to Allocation To date.



59

3. GOI Order Date would be a mandatory field for user. GOI Order Date should be less than “Allocation To

Date”.

4. Scheme Group and Scheme Name would be a mandatory field. Based on the selection of “Scheme

Group”, scheme name dropdown should be populated with the appropriate values. Scheme Name

dropdown should only show those schemes which would be mapped to the respective Scheme groups

5. Multiple Commodity Details can be added in one State Allocation.

6. Commodity Name would be a mandatory field.

7. Allocation Type would also be a mandatory field having the values as: “Regular/Additional/ Ad hoc”.

8. GOI Allocation Order Validity date field would be mandatory and greater than GOI Order date.

Revenue District Wise Allocation: To update Revenue District wise Allocation details, user would modify the below fields:

State

GOI Allocation Orders Dated between (From and To)


Select State Allocation Year & Month


Allocation Order Date

Scheme Group

Select Scheme

Based on updating above fields, user would modify below commodity related details: Commodities Details

Revenue District

Commodities

Total State Allocation

Payment Cutoff Date

Enter Allocation (MT up to 3 decimal places)


Business Rules and Validations: 1. GOI Allocation orders Dated between (From and To) would be mandatory for user. GOI Allocation from

date should be less than or equal to GOI Allocation To date.

2. GOI Allocation Order No. field would populate only those orders falling between the GOI Allocation

orders from and To Date selected.

3. Based on the GOI Allocation order No. selection, Scheme group as well as scheme name dropdown

would only show the mapped appropriate values .

4. Special character would be restricted in Allocation Order No. except ‘/’ and ‘-‘.

5. Based on the GOI Order No., Commodity field would only show the mapped appropriate values.

6. Revenue District field would be mandatory and populate the values based on State selected by the user



60

7. Allocation should be segregated across the revenue districts.

8. The total Quantity should be less than or equal to the total Quantity of the state allocation.

Requirement 3#: Ability to send an e-Mail/SMS to concerned officers, once the allocation is digitized or captured from external applications.

Solution: To address the above requirement, e-Mail/SMS facility would be integrated with Release order application and e-mails/SMS would be shared to related authorities on any action.

4.2.1.2 INDENT

Indent letter would be generated by the State agency/party which includes the scheme, commodity and payment details. FCI District office would verify the payments details and send indent to competent authority for approval. Once indent approved by competent authority the Release Order Creation process would start. Below are the functional requirements for the Indent generation process.

1) Create New Indent

2) Approve Indent

3) Make Payment

4) Sales Approve

Requirement 1#: Application should have ability to create a new indent.

Solution: In Create New Indent module, user will be provided with below details to fill so that Indent Creation activity can be performed.

FCI District

Revenue District **

Allocation Year/Month

Name of State Agency Party

State Government Allocation Order Number

State Govt. Allocation Order Date

Payment Cut-off Date

GOI Allocation Order Number

Scheme Details

Central Scheme Name

Commodity

Total Allocation Quantity (MT)

Available Quantity (Qtl.Kg gms)

Quantity (Qtl.Kg gms)

CIP/Issue Price (Rs./Qtl.Kg gms)

Cost of Food Grains

Tax / VAT / Other Charges



61

Tax Name

Tax Rate

Tax (Rs.)

Cess (Rs.)

Total (Rs.)

Deduction Details

Deduction Details

Amount

** Note: (1) One Revenue District is being served by more than One FCI District. VC is proposed against the same,

example Durgapur and Burdwan in West Bengal Region.

(2) Provisioning for sub division allocation.

Business Rules and Validations:

1. FCI District and Revenue District would be populated automatically for which logged in user is

authorized.

2. User would select Allocation Month and Year. “State Government Allocation Order Number”

would be populated based on selected Month and Year.

3. User would select “State Government Allocation Order Number” and “State Govt. Allocation

Order Date”. Based on the selection against both the fields, “GOI Allocation Order Number”

should be populated accordingly.

4. After performing step from 1 to 3 user would provide Payment Cut-off Date which should be

greater than or equal to today’s date. This input is mandatory for user.

5. User would provide Commodity details. One Indent should capture only one commodity.

6. Quantity should be entered less than or equal to Available Quantity. Available Quantity will refer

to quantity for which Indent is pending.

Quantity Available for Indenting/Off take = Total Allocation – Total Quantity Indented

7. CIP/Issue price will be populated from CIP/Rate master database as per selected commodity.

8. Cost of Food Grains would be calculated by the system.

Cost of Food Grains = (Quantity * CIP/issue price) + Applicable Taxes

9. User can add multiple Tax / VAT/ Other Charges for the currently added commodity. Based upon

the Tax Name selection “Tax Rate” and “Tax” will be calculated

Total Tax= Tax + Cess

10. Multiple Deductions can be added for the current commodity.

Indent Amount= Cost of Food Grains + Tax Cost – Deductions (if any)

11. Multiple indents can be created against a revenue district allocation.

Requirement 2#: Application should have ability to approve or reject the current indent details by Indent Approver.



62

Solution: To address the above requirement user would be provided with below details to fill so that Indent Approve/Reject activity can be performed. Authorize user will be log in the Application and will select Indent Approve module, where user will provide Date From and Date To as input and user will see details of Indent between given date range which are created for that Revenue District for which user (Approver) is authorized to approve. User will see below details in Awaiting Approval (which are waiting for approval) and Approved (which are approved by user) section.

Awaiting Approval

S.No.

Indent Number

Allocation No.

Indent Submission Date

Indent Status

Approved

S.No.

Indent Number

Allocation No.


Indent Status

By selecting “View/Approve” option of any row item displayed in Awaiting Approval list user will move Indent Approve/Reject module.

o Indent Approve/Reject: In Indent Approve Reject module user will be provided with below details to

view and fill required input details so that Indent Approve/Reject activity can be performed.

Indent No.


FCI District

Revenue District

Allocation Year & Month

Name of State Agency / Party




Payment Cut-off date

Schemes Indented By State Agency / Party

Central Scheme Name

Commodity

Quantity

CIP/Rate(Rs./Qtl.Kg gms)

Cost of Food Grains



63

Business Rules and Validation:

1. User will get indent of that Revenue District for which he/she is authorized.

2. All the details of indent which will appear to approver are only which are captured at the of

Indent creation.

3. User has to enter Approved Remarks or Reject Remarks for the Indent.

4. Approved Indent will be appearing for payment.

5. User will get a message as status of action.

Requirement 3#: Application should allow the user to provide the payment details. Application should consider the previous balance amounts if any, while generating the current payment details of the current month.

Solution: To address the above requirement user will be provided with below modules by using user can capture payment details.

o Make Payment

o Payment Type

o Make Offline Payment

o Make Payment: In Make Payment module user will be provided with below details of Indent to view

List of Approved Indents

S.No.

Indent Date

Indent No.

Indent Approval Date

State Allocation Order Number

State Allocation Order Date

Amount To Be Paid

Amount Paid

Payment Cut-off Date

User will select Pay Now option against any listed items to process the payment and user will see indent details and pending indent amount of last month to be paid.

Payment Type: In Payment Type module user will be provided with below details to view. Un-utilized Payments details are pending Indent Amount of last month

State Agency Party Name

Indent No.

Indent Date

Indent Approved Date





64

Indent Amount (INR)

Amount Paid Till Date

Partial Payment Details for Indent No.

S.No.

Payment Mode

Authorization of Cash

Bank Name

Branch

IFSC Code

Payment Date

Transaction / Ref. No.

Amount Paid

FAP Receipt

Un-utilized Payments

S.No.

Description

Amount

User will see Offline and Online Payment options. If user will select Online user will move to Payment page of Bank website. If user will select Offline user will move Make Offline Payment page.

Make Offline Payment: In Make Offline Payment module user will be provided with below details

State Agency Party Name

Indent No.

Indent Date

Indent Approved Date



Indent Amount (INR)

Amount Paid Till Date

Payment Details

Payment Mode

Bank Name

Payment Date

Branch Name

Payment Instrument No.

IFSC Code

Amount Paid

Upload Payment Proof



65


1. Upload Payment Proof is mandatory for every payment.

2. Payment Date should be equal or less than today’s date.

3. When we select “Payment Mode” as DD, Cheque, Bank Challan, NEFT, RTGS the bank details,

Amount and Payment Instrument No. are mandatory.

4. When we select “Payment Mode” as Cash the Details of Authorization of Cash and Amount are

mandatory.

5. User will make payment Online/Offline, payment details will be updated in FAP Application

against selected Indent Details. It will happen though a service.

Requirement 4#: Application should allow the FAP user to verify the payment details which in-turn is verified from the FAP Application. After verifying the payment made by the State agency/party gives the confirmation for proceeding with the indent generation process. Solution: To address the above requirement user will be provided with FAP Approval module by using FAP user can verify payment details.

o FAP Approval: In FAP Approval module user will be provided with below details to which user need to

verify.

List of Pending FAP Approvals

S.No.

Indent Date

Indent No.

Indent Approval Date

State Allocation Order Number


State / Party Name

Amount Paid

Document Number

Receipt Number

Remarks

View Payment Receipt

User will select “Request FAP Approval” option against any pending item from list and user will move on Payment Verification page. FAP Approve / Reject: Before approval FAP user has to enter receipt No. and document No. from FAP module to RO module in the relevant fields in FAP Approval screen. In this screen, FAP user will be provided with the following fields

Approve / Reject Option

Document Number

Receipt Number



66

Approved / Reject Remarks

Upload FAP Receipt


1. FAP User can upload Receipt in PDF Format.

2. FAP user will verify and approve the payment details. In case payment is not available then FAP user

has option to reject the indent with rejection remarks.

Requirement 5#: Sales division can approve or reject the current indent details vis-à-vis the amount deposited and the quantity indented.

Solution: To address the above requirement user will be provided with “Approve Indent by Sales section”, here users will Approve or Reject Indent details.

o Approve Indent By Sales: In “Approve Indent By Sales” section user will be provided with below details

from Approval or Rejection. User will get two list Awaiting Approval (which are waiting for approval) and

Approved (which are approved by user) section. Here user will get From To Date option, by providing

date range user will get indent details held under given date range as below:

Awaiting Approval

S.No.

Indent Number

Allocation No.


Indent Status (FAP Approved/Rejected)

Approved

S.No.

Indent Number

Allocation No.


Indent Status (Sales Approved/Rejected)

User will see above details of indents which are approved or waiting for approval by Sales Manager. When user will select “View/Approve” option user will move on Indent Approval/Rejection module.

Indent Approve Reject: In Indent Approve Reject module user will be provided with below details

Indent No.


FCI District

Revenue District

Allocation Year & Month

Name of State Agency / Party



67




Payment Cut-off date

Schemes Indented By State Agency / Party

Central Scheme Name

Commodity

Quantity


Cost of Food Grains

Schemes Indented By Sales Manager

Total State Allocation Quantity (Qtl.Kg gms.)

Indented Quantity (Qtl.Kg gms.)

Total Amount

Paid Amount

Entitled Quantity (Qtl.Kg gms.)

Approved Quantity (Qtl.Kg gms.)

Business Rules and Validation: 1. Approved Quantity should be less than or equal to Entitled Quantity.

2. User can approve partial indent on the basis of Total and Paid Amount.

Requirement 7#: Ability to send an e-Mail/SMS to concerned officers once the allocation is digitized or captured from external applications.

Solution: To address the above requirement e-Mail/SMS would facility would be integrated with Release order application and e-mails/SMS would be shared to related authorities on any action.

4.2.1.3 RELEASE ORDER

Release Order generation talks about the steps involved in creation of the Release Order based on the Indent received from the State agency/party. Following are the functional requirements for the Release Order generation process. Requirement 1#: Ability to add the commodity details based on the State agencies /parties indented commodity details for the new schemes.

o Create New Release Order

o Approve Release Order

To address the above requirement “Create New Release Order”, “Approve Release Order” modules would be provided to the user. Those users having permission to access Create New Release Order or



68

“Approve Release Order” modules would log in the application with valid credential and Create New Release Order or Approve Release Order. User would be provided with below details

o Create New Release Order: In Create New Release Order module user will be provided with below

details

Commercial/Sales Approved Indent No.

View Stock Position

Select Commodity

Select Depot

FCI Depot for Offtake

Release Order No.

Release Order Date

GOI Allocation Order No. & Date

Allocation Month & Year

State Agency/ Party

Issued to Revenue District

FCI District

Schemes Indented By State Agency / Party Details

Central Scheme Name

Commodity

Indented Qty (Qtl.Kg gms)

Sales Officer Approved Qty(Qtl.Kg gms)


Indenter Cost Of Food Grains

Release Order Commodity Details

Central Scheme Name

Commodity Name

Available Indenter Qty(Qtl.Kg gms.)


Issued Qty(Qtl.Kg gms.)

Amount


1. User will get select option to FAP Approved Indent No., FCI Depot for Off take. On the basis of selected

Commercial/Sales Approved Indent No., FCI Depot for Off take - Release Order No. auto generates.

2. GOI Allocation Order No. & Date, Allocation Month & Year, State Agency/ Party, Issued to Revenue

District, FCI District will be populated on the basis of selected FAP Approved Indent No.

3. Release Order date will be today’s date.

4. Schemes Indented By State Agency / Party details will be populated on the basis of selected

Commercial/Sales Approved Indent No..



69

5. Based on the stock availability user will create the Release Order. User will check stock position by

clicking on “View Stock Position” hyperlink.

6. Only one commodity/scheme can be added in one Release Order.

7. Quantity of Release Order can’t be more than approved Indented Quantity.

8. Multiple “Release Orders” can be created against one approved Indented Quantity. After creating one

Release Order, when user will create another Release Order against same Indent, Release order can be

issued for remaining quantity only.

Available Quantity for Release Order against Indent Number = (Total Indented Quantity against

Indent Number – Release Order Allotted Quantity against that Indent Number)

Commodity Cost = (CIP/Issue Price * Issued Quantity)

Total Release Order Cost = (Commodity Cost + Applicable Tax/Vat/Others Charges - Deductions)

Requirement 2#: Ability to approve or reject the current Release Order details by User.

o Manage Release Order

o Release Order Approve Reject

o Release Order Manage: In Manage Release Order module user will be provided with below details

Awaiting Approval

Release Order No.

Release Order Submission Date

Indent No.


FAP Approval Date

Approved

Release Order No.

Release Order Submission Date

Indent No.


FAP Approval Date


1. User able to generate the physical copy of the Release Order with Digital Signature which is mandatory.

o Release Order Approve Reject: In this module user will be provided with below details. This form will

appear when we click on View/Approve button in Release Order Manage page.



70

FCI District Office - Release Order Verification and Approval

FAP Approved Indent No.

State Allocation Month & Year

GOI Allocation Order No. & Date

FCI Depot for Offtake

FCI District

Release Order Date

Release Order No.


State Agency/ Party


Central Scheme Name

Commodity

Indented Qty (Qtl.Kg gms)

Sales Officer Approved Qty(Qtl.Kg gms)


Indenter Cost Of Food Grains

Release Order Commodity Details

Commodity Name

Central Scheme Name



Amount

Release Order Cost Details

S.No.

Commodity Name

Central Scheme Name



Amount

Business Rules and Validation: 1. User has to select validity date for the Release Order.

2. Release Order Validity date will be greater than to Today date and should not be more than lifting

duration.

3. User has to upload the Digital Signature at the time of Release Order Approval.

4. User has to enter Approval Remarks or Rejection Remarks for the Release Order.

Requirement 3#: Ability to use the existing common master data to populate the values. To address the above requirement, below masters data would be provided to the user.

State



71

FCI District (mapped with corresponding Revenue District)

Revenue District (mapped with corresponding FCI District)

State Agency/Party

Commodity

Commodity Category

CIP/Issue Price (State wise)

Tax (State wise)

Bank

Bank Branch

Requirement 4#: Ability to send an e-Mail/SMS to concerned officers once the Release Order is digitized or captured from external applications.

To address the above mentioned requirement, e-Mail/SMS would facility would be integrated with Release order application and e-mails/SMS would be shared to related authorities on any action.

4.2.1.4 INFLOW The Food Corporation of India purchases food grains from producers during both the seasons, directly or through the agency of co-operatives or purchasing agents, and from millers under various arrangements of procurement determined by different State Governments. FCI undertakes the procurement of food grains on behalf of Government of India and State Governments where it has been entrusted with this responsibility either as a sole agency or jointly with other public procurement agencies. Following are the functional requirements for the Inflow process:

Requirement 1#: Application should have ability to add the commodities as per vehicle challan by Gate Entry Operator.

o Gate Entry - Loaded Truck

o Generate Token Number

o Gate Exit – Empty Truck

Gate Entry – Loaded Truck: In Gate Entry – Loaded Truck module, user will be provided with below details

Vehicle Challan No.

Vehicle Challan Date

Vehicle No.

Driving License No.

Driver Name & Mobile No.

Source of Inflow



72

Entry Date & Time

Loading Date at Source

Consigner

Consignee

Commodity Details as Per Vehicle Challan

Commodity Name

No. of Bags

Bag Type (BT/SBT/PP)

Quantity (Qtl.Kg gms.)


1. Vehicle Challan Date should be less than or equal to today’s date.

2. Entry Date should be current date.

3. Loading Date at Source should be less than or equal to today’s date.

4. Single Commodity details will be allowed.

Generate Token Number: In “Generate Token Number” section, user would be able to generate the physical copy of token number.

Vehicle Challan No.


Vehicle No.

Driving License No.


Source of Inflow

Entry Date & Time


Consigner

Consignee


Commodity Name

No. of Bags



Business Rules: 1. Token Number to be printed must be a valid token number.

Gate Exit – Empty Truck: In Gate Exit Empty Truck user will be provided with below details

Vehicle Challan No.


Vehicle No.



73

Destination Depot Name


Driving License No.

Entry Date & Time

Source of Inflow


Consigner

Consignee

Loaded Weight of Truck

Weighment Date

Tare Weight of Truck

Weighment Time

Remarks

Commodity Unloaded

Commodity

Crop Year


Issuable?

Category

Specification

Type of Labour


Gang No.

Labours Used

Type of Operation

Storage Type

Unit No.

Stack No.

No. of Bags Unloaded

S No.

Commodity


As Per Vehicle Challan

Bags


As Per Unit Shed

Bags


Tare Weight Of Bags (Qtl.Kg gms.)

Gross Weight Of Commodity (Qtl.Kg. gms)

Net Weight Of Commodity (Qtl.Kg gms.)

Exit Details

Exit Date & Time



74


1. Token Number to be printed must be a valid token number.

2. Exit date should be current date.

3. All the weighment details should come from the Open xml data format.

Requirement 2#: Application should have ability to get the weighment details by Weighbridge Operator.

o Weighbridge Room - Loaded Truck

o Weighbridge Room – Empty Truck

Weighbridge Room - Loaded Truck: In Weighbridge Room - Loaded Truck module, user would perform weighment of the loaded truck which was entered into the weighbridge room.

Vehicle Challan No.


Vehicle No.

Destination Depot name


Driving License No.

Entry Date & Time

Source of Inflow


Consigner

Consignee


Commodity Name

No. of Bags



Loaded Truck Weight

Weighbridge Identification No.

Weighbridge Room - Empty Truck: In Weighbridge Room - Empty Truck module, user would perform weighment of the empty truck which was entered into the weighbridge room.

Vehicle Challan No.


Vehicle No.



Driving License No.

Entry Date & Time

Source of Inflow



75


Consigner

Weight of the Commodity as per 10% Weighment Rule

Loaded Vehicle Weight as Per Weighbridge

Consignee


S No.

Commodity Name

No. of Bags



Commodity Unloaded

Commodity

Crop Year


Issuable/Non Issuable

Category

Specification

Type of Labour


Gang No.

Labours Used

Type of Operation

Storage Type

Unit No.

Stack No.


Weighment Details

Loaded Weight of Truck

Tare Weight of Truck

Date & Time

Remarks

S. No.

Commodity


As Per Vehicle Challan

Bags


As Per Unit/Shed

Bags


Tare Weight Of Bags (Qtl.Kg gms.)

Gross Weight Of Commodity (Qtl.Kg. gms)



76

Net Weight Of Commodity (Qtl.Kg gms.)



2. Date should be current date.

3. Time should be current time.

4. Tare Weight of Truck should be less than the Loaded Weight of Truck

5. Values of “Gross Weight of Commodity” and “Net Weight of Commodity” are display based

upon the values of “Loaded Weight of Truck” and “Tare Weight of Truck”.

6. All the weighment details should come from the Open xml data format. Where ever

weighbridges do not have a capability to exchange data in open data format, the weighment

details shall be manually fed at weighbridge/gate..

7. In case of Rail Siding Depot, internal movement/rail movement, truck shall be tare weight every

time.

Requirement 3#: Application should have ability to add the commodities as per unit/shed by Unit/Shed In charge.

o Unit / Shed

Unit / Shed: In Unit / Shed module, user will be provided with below details

Vehicle Challan No.


Vehicle No.



Driving License No.

Entry Date & Time

Source of Inflow


Consigner

Consignee


Weight of the Commodity as per 10% Weighment Rule.


S. No.

Commodity Name

No. of Bags



Commodity Unloaded

Commodity

Crop Year



77



Category

Specification

Type of Labour


Gang No.

Labors Used


Type of Operation

Storage Type

Unit No.

Stack No.



2. Unit Shed Bag Type should be same as of vehicle challan Bag Type.

Requirement 4#: Application should have ability to add the commodity received as per Rail Movement by Depot manager

o Rail Movement - Inflow

Rail Movement - Inflow: In Rail Movement - Inflow module, user will be provided with below details

Rail Details

Special No.

Special Dispatch Depot / Station

Special Dispatch Date

Special Arrival Depot / Station

Special Arrival Date & Time

Special Release Date & Time

Commodity Received

Unit No.

Stack No.

Commodity

Crop Year



Category

Specification

Type of Labour



78


Gang No.

Labours Used

Type of Operation

No. of Bags Loaded

Weighment Mode


1. Special Indent Date should be less than or equal to today’s date.

2. Special Dispatch/Release Date should be greater than or equal to today’s date.

Requirement 5#: Ability to use the existing common master data to populate the values. To address the above requirement, below masters would be provided to the user.

Depot

Revenue District

Commodity


Crop Year

Issuable

Category

Specification

Type of Operation

Storage Type

Weighment Mode

4.2.1.5 OUTFLOW FCI release the food grains to State agencies / parties under various schemes as per the allocation guidelines prescribed by Department of CA, F&PD. Release Order application should capture the commodity loaded and commodity unloaded details for a particular Release order/ Dispatch order Number. Following are the functional requirements

Requirement 1#: Application should have ability to add the commodities as per Release order/Dispatch No. by Gate Entry Operator.

o Gate Entry - Empty Truck

o Generate Token Number

o Gate Exit – Loaded Truck/ Empty Truck (in case of exceptions)



79

Gate Entry – Empty Truck: In Gate Entry – Empty Truck module, user will be provided with below details

Vehicle No.

Driving License No.


Entry Time

Release Order/Dispatch No.

Entry Date

Consigner

Consignee


1. Entry Date and time should be current.

2. Details will be populated based on Release order No. selection.

3. Dispatch No. should be entered if Release order not selected.

4. In case Dispatch No. , Rail movement or Internal Transfer should be selected.

5. In case Rail Movement Consignee will become free text to enter.

6. In case Internal Transfer Depot name should be selected.

Generate Token Number: In “Generate Token Number” section user would be able to print physical copy of the following details and token number.

Vehicle No.

Driving License No.



Entry Date and Time

Consigner

Consignee


1. A valid token number is one as long as the truck is within the Depot premises.


Gate Exit – Loaded Truck: In Gate Exit Loaded Truck user will be provided with below details

Vehicle No.



Driving License No.

Entry Date and Time



80

Consigner

Consignee

Tare Weight of Vehicle


Commodity Loaded

Unit No.

Stack No.

Commodity


Crop year

Issuable

Category

Specification

Type of Labour

Gang No.

Labour Used

Type of Operation

No. of Bags

Quantity

Commodity Unloaded

Commodity

Crop Year



Category

Specification


Added /Taken back Loose Grains





3. Truck Number will be fed in running order without space.

4. Gate pass shall be prepared/generated by Unit/Shed In-charge.

5. Exit date should be current date and time.

6. Exit Gate Pass No. should be validated with generated Gate Pass No..



details shall be manually fed at weighbridge/gate.



81

Requirement 2#: Application should have ability to get the weighment details by Weighbridge Operator.

o Weighbridge Room - Empty Truck

o Weighbridge Room – Loaded Truck

Weighbridge Room - Empty Truck: In Weighbridge Room - Empty Truck module user will be done weighment of the empty truck which was entered into the weighbridge room.

Vehicle No.



Driving License No.

Entry Date

Entry Time

Consigner

Consignee

Release Order /Dispatch No.

Tare weight of vehicle







details shall be manually fed at weighbridge/gate.

Weighbridge Room - Loaded Truck: In Weighbridge Room - Loaded Truck module user will be done weighment of the loaded truck which was entered into the weighbridge room.

Vehicle No.



Driving License No.

Entry Date and Time

Source of Inflow


Consigner

Consignee

Commodity Loaded

Unit No.

Stack No.

Commodity




82

Crop year

Issuable

Category

Specification

Type of Labour

Gang No.

Labour Used

Type of Operation

No of Bags

Quantity

Commodity Unloaded

Commodity

Crop Year



Category

Specification




Requirement 3#: Application should have ability to add details of the commodity (No. of bag, specification etc.) as per unit shed by Unit Shed In charge.

o Unit / Shed

o Generate Exit Gate Pass

Unit / Shed: In Unit / Shed module, user will be provided with below details

Vehicle Challan No.


Vehicle No.



Driving License No.

Entry Date and Time

Consigner

Consignee


Weight of the Commodity as per 10% Weighment Rule.

Commodity Loaded

Unit No.

Stack No.



83

Commodity


Crop year

Issuable

Category

Specification

Type of Labour

Gang No

Labour Used

Type of Operation

No. of Bags

Quantity

Commodity Loaded

Commodity

Crop Year


Issuable/ Non Issuable

Category

Specification



No. of Bags Loaded




3. Duplicate Commodity details will not be added.

Generate Gate Exit Pass: In Generate Gate Exit Pass module, user would be able to generate the physical copy of the commodity details, commodity loaded details, token number and gate exit pass.

Vehicle No.



Driving License No.

Entry Date and Time

Consigner

Consignee

Tare weight of Vehicle

Weighbridge Instrument No.

Commodity Details



84

S No.

Unit No.

Stack No.

Commodity Name

No. of Bags


Commodity Unloaded (Loose Grains Loaded/Taken back)

S No

Commodity



No. of Bags loaded



2. Truck Number will be fed in running order without space.

3. Gate pass shall be prepared/generated by Unit/Shed In-charge.

Requirement 4#: Application should have ability to take action on Release Order/Dispatch Order in case of exigencies like Initiation of RO Diversion, Closing of RO, Re-weighment etc..

o Depot Manager - Outflow

Depot Manager - Outflow: In Depot manager - outflow module, user will be provided with below details

Review pending details grid

Token No.

Release Order No.

Release Order Date

Entry Date Time

Amount


1. The list of Release Orders against which action has already been taken shall not be available to

the depot manager.



85

4.2.1.6 DIVERSION In case of stock unavailability or where stock can’t be lifted from designated depot, Commercial section of FCI District office diverts the Release Order to any feasible depot within same FCI district. In case Release Order needs to be diverted to any depot beyond the FCI district, Regional office authorizes the Release Order diversion to any depot of other district. User would be provided with below sub- modules under Diversion:

o Manage RO diversion

Below are the functional requirements for Manage RO Diversion:

Requirement 1#: Ability to view the Diverted Release Orders along with associated FAP receipt Solution: Under Manage RO Diversion, user would be able to view the below details related to diverted Release orders:

S.No.

RO No.

RO Creation Date

RO Approval Date

RO Validity Date

State Agency/Party

RO Quantity (Qtl.kg gms)

Quantity Lifted (Qtl.kg gms)

Unlifted Quantity (Qtl.kg gms)

Amount

FAP Receipt: Clicking on “FAP receipt” button, user would be able to view the FAP receipt of

the corresponding diverted release order

Business Rule and Validation: 1. In case of release order validity expiry, same release order should not be shown under Release order list Requirement 2#: Ability to divert a release order Solution: To address the above requirement, user would perform below operation:

Selecting the values from “RO Diversion Type” field

Entering IOG No.

Entering Remarks

Post entering the above details, user would be able to start the process of release order diversion.

In “Manage RO Diversion”, the user would also be provided with options saying “Awaiting Approval” as well as “Approved”.

a. Awaiting Approval: User would be able to find list of awaiting RO diverted list for his/her approval.



86

b. Approved: User would be able to see all the approved RO by him/her.

Note: User would also be able to see the release order details by clicking “View Release Order Details”.


1. IOG No. field should be populated only when RO Diversion Type is selected as “Diversion within

FCI District” and “Diversion to another FCI district outside region”

o Create New Release Order

In Create New Release Order, user can view all approved diverted RO list in dropdown where he/she can create new release order (RO No. will same) against Diverted RO and RO will be assigned to new FCI depot for off take. Requirement 1#: Ability to assign a new FCI depot for off take against a commodity Solution: To address this requirement, system would provide depot dropdown for commodity off-take Business Rules and Validation: 1. Quantity should not be greater than the Balance Quantity against that diverted RO

4.2.1.7 EXTENSION State agency/party shall request for extension, if the State agency/party fails to lift the commodity in the validity period of Release Order. Extension module has below sub modules:

o Manage RO Extension

o Extend RO

o View RO

Following are the functional requirements of the Release Order extension process. Requirement 1#: Ability to extend the validity date of expired Release Order by indenter, Approve or Reject the RO Extension request by Area Manager or General Manager. Solution: To address the above requirement, “Manage RO Extension”, “Extend RO” and “View RO” modules would be provided to the user. Those users having permission to access Manage RO Extension, Extend RO and View RO module would log in the application and request for extension and approve or reject that request. User would be provided with below details

o Manage RO Extension: In Manage RO Extension module user will be provided with below details

http://182.72.216.214:81/ROExtension/ManageROExtension#AwaitingApproval



87

Release Order List

S. No.

RO No.

RO Creation Date

RO Approval Date

RO Validity Date




Deposited Amount

RO Extension Status and Authority

RO Extension Validity date

Awaiting Approval

S. No.

RO No.

RO Creation Date

RO Approval Date

RO Validity Date

State Agency / Party




Deposited Amount

Extension Request Date

Approved

S. No.

RO No.

RO Creation Date

RO Approval Date

RO Validity Date


Deposited Amount

Extend RO Approval Date and Authority

RO Extension Validity date

o Extend RO: In Extend RO module user will be provided with below details

Release Order Details



FCI District

FCI Depot for Off-take

Release Order No.



88

Release Order Date

State Agency/ Party


Release Order Validity

RO Quantity

Quantity Lifted

Unlifted Quantity


Central Scheme Name

Commodity

Quantity


Cost Of Food Grains

Release Order Commodity

S.No.

Commodity Name

Central Scheme Name



Amount

Deduction Based on Indent Submitted by State Agency / Party

S.No.

Deduction Details

Amount

Release Order Cost

S.No.

Commodity Name

Central Scheme Name



Amount


No. of days

Remarks

Business Rules and Validation: For PDS/OWS 1. FCI Area Manager will not have power to extend the RO.

2. GM (Region) can extend the RO up to first 15 days including processing period. 2. ED (Zone) can extend the RO up to next 15 days (16th to 30th Day) including processing period.



89

3. Ministry can extend the RO after the 30th day for no limit. 4. Remarks should be entered by the designated officers for not lifting the commodity by extended time.

For OMSS 1. Will be governed as per MTF.

o View RO: In Extend RO module user will be provided with below details

Release Order Details



FCI District


Release Order No.

Release Order Date

State Agency/ Party


Release Order Validity

RO Quantity

Quantity Lifted

Unlifted Quantity


Central Scheme Name

Commodity

Quantity


Cost Of Food Grains

Release Order Commodity

S.No.

Commodity Name

Central Scheme Name



Amount

Deduction Based on Indent Submitted by State Agency / Party

S.No.

Deduction Details

Amount

Release Order Cost

S.No.

Commodity Name

Central Scheme Name




90


Amount


Release Order Validity Date

RO Extension Requested Days

Action(Approve/Reject)

RO Extension Validity Date

Remarks


1. Ability to select Action(Approve/Reject),

2. Validity will be defined as per MTF.

Requirement 2#: Ability to send an e-Mail/SMS to concerned officers once the Release Order is digitized or captured from external applications. Solution: To address the above requirement e-Mail/SMS would facility would be integrated with Release order application and e-mails/SMS would be shared to related authorities on any action.

4.2.1.8 STOCK PROCESSING

Unit Shed In charge shall Upgrade/Downgrade of the commodities. Following are the functional requirements for the Upgrade/Downgrade or Gain/Loss process

Requirement 1#: Ability to Upgrade/Downgrade of the commodities by Unit Shed Incharge.

o Upgrade/Downgrade

o Gain/Loss

To address the above requirement “Upgrade/Downgrade” and “Gain/Loss” modules would be provided to the user. Those users having permission to access Upgrade/Downgrade and Gain/Loss module would log in the application with valid credential and Upgrade/Downgrade or Gain/Loss of the commodities. User would be provided with below details

Upgrade/Downgrade: In Upgrade/Downgrade module of Stock Processes user will be provided with below details

Upgrade/Downgrade – Adding

Storage Type

Unit No.

Stack No.

Commodity

Crop Year



91


No. of Bags

Issuable?

Category

Specification

Quantity


1. Ability to select Storage Type, Unit No., Stack No., Commodity, Crop Year, Bag Type

Issuable?, Category, Specification.

2. Ability to enter No. of Bags, Quantity.

Upgrade/Downgrade – Editing

Storage Type

Unit No.

Stack No.

Commodity

Crop Year


No. of Bags

Issuable?

Category

Specification

Quantity

Business Rules and Validations: 1. Ability to select Storage Type, Unit No., Stack No., select Bag Type Issuable?, Category, Specification.

Gain/Loss: In Gain/Loss module of Stock Processes user will be provided with below details

Gain/Loss – Adding

Storage Type

Unit No.

Stack No.

Gain / Loss Type

Commodity

Crop Year


Category

Specification

Issuable?



92

No. of Bags

Quantity


1. Ability to select Storage Type, Unit No., Stack No., Commodity, Crop Year, Bag Type, Category,

Specification, Issuable?.

2. Ability to enter No. of Bags, Quantity.

Gain/Loss – Editing

Storage Type

Unit No.

Stack No.

Gain / Loss Type

Commodity

Crop Year


Category

Specification

Issuable?

No. of Bags

Quantity


1. Ability to select Storage Type, Unit No., Stack No., Bag Type, Category, Specification, Issuable?.

4.2.1.9 NCDEX RO NCDEX RO is used to create a release order against the tendered commodity (OMMS (D)). Requirement #1:

Create NCDEX RO: concern user can see this option and create a new NCDEX for particular party, FCI dist and FCI depot for off take. Scheme group will be the OMMS (D) only. And capture payment details also.

NCDEX Release Order No.

NCDEX Release Order Date

FCI District


Release Order No.

NCDEX RO Validity Date


Scheme Group



93

Scheme Name

Commodity Name

Rate(Rs./Qtl)


Amount

Payment Mode

Payment Date

Payment Instrument No.

Amount paid

Bank Name

Branch Name

IFSC Code

Upload NCDEX RO

Business Rule and Validations:

1. Release Order No. : Combination of NCDEX/RO/FCI depot Code/Running No. Ex :

NCDEX/RO/NG19002/00003

2. Only OMSS scheme group is available for NCDEX RO.

3. Digital signature will be mandatory for NCDEX RO.

4. No Payment verification from FAP Application is required as RO is already generated.

Requirement #2:

After creating the NCDEX RO, The same release order will appear for approval to the concern user. He will either approve or reject with approval/Rejection remarks.

NCDEX RO No.

NCDEX RO Creation Date

NCDEX RO Validity Date

RO No.

Party Name

Amount

After viewing particular record: user can approve as well as reject

4.2.1.10 RO REIMBURSEMENT All the balance quantity or amount paid by state agency or party for which commodity has not been lifted can go for reimbursement the amount of the balance or whole quantity. Quarterly report of such expenditure will be presented in the FCI Board. Business Rule and Validation:



94

1. Payment has to verify from FAP and lifted quantity against the payment has to verify from the RO

application.

2. During reimbursement amount should not be excess from the amount of balance quantity.

3. After successful reimbursement of a release order the same has to close by district officer.

4.2.2 DATA EXCHANGE ENGINE Data Exchange engine is responsible for implementing the business functionality to transfer the information between the proposed Release Order application with other external applications to perform the Release Order operations. It allows maintaining the data consistency and uniformity between all the applications. Data exchange engine module talks about linking the external applications with Release Order application. Following are requirements to implement the data exchange module.

1. To identify the data exchange parameters.

2. Data exchange bi-directional/uni-directional.

3. Data exchange approaches

a. Backend database scripts

b. XML web services

c. simple flat/CSV file

d. Any other open data format

4. Database Sync Requirements

a. Time period

b. online/offline

c. Communication technology

Release Order application shall be linked with existing external applications to perform the Release Order operations workflow.

1. FAP - Financial Accounting Package – For creation of invoices in FAP. Data will be consumed by FAP

application through XML web services in consultation with FAP/FAP vendor (which is maintaining the FAP

Application) after finalization of Release Order Application SRS.

2. FEAST – Food and Essential Commodities Assurance & Security Target – To handle the State level allocation

details for the TPDS schemes

3. SIMS – Stakeholder Inventory Management System – To get the State agency officers details for TPDS

schemes.

4. DCMS – Depot Code Management System - To find the active depots in the FCI District.

5. IRRS - IISFM Rapid Reporting Services – To get the depot wise stock positions details.

6. Integration with Weighbridge - to handle the inflow and outflow stocks management in Depot.



95

4.2.3 WEB PORTAL The development of web portal for Release Order Application means creating a website in which the management of all Release Order operations could be done online. This portal is designed using industry standard .Net technologies with MS SQL Server as a backend database. Web Portal, is an online reporting with executive dashboard application which allows stakeholders to perform the Release Order tasks. It allows the users to track and monitor the Release Order status online. It includes following components

1. GUI Screens to perform the Release Order Operations online

2. Executive Dashboard for overall portal administration and configuration

User Management.

Schemes based State/Revenue District wise allocations.

Depot/FCI District/Revenue District/State/Zone/Country wise Stock Positions.

Status of the Release Orders and off take against the Release Orders.

Schemes details along with CIP and validity period etc.,

3. Online Reports to track and view the Release Order Operations.

Allocation – State, Revenue and FCI District-wise.

Indent Generation Reports Release Order Generation Reports.

Release Order Progress Reports.

Online stock lifting Status Reports against the Release Orders.

Release Order Exceptional Reports – (Diversion, Extension and Reimbursement Reports).

Daily Release Order Deposit.

Scheme Commodity wise Issues.

Release Orders between Dates.

Scheme & Commodity wise Issues Summary.

Scheme wise Issues.

Single RO Scheme wise Issues Commodity wise.

Statement of Issue Date wise.

4.2.3.1 FUNCTIONAL REQUIREMENTS

1. Web Portal shall be built on a multi-tiered, distributed architecture, including object-oriented design, event-

driven programming design, and transaction-based processing.

2. Ability to create, edit and view different user groups. A user group is assigned privileges of reading, writing

application resources, e.g. user management screen, information entry screen etc.

3. Ability to create a new system user in an already created group and then to edit and view the user

information.

4. Allows administrators to easily manage users and groups through a GUI interface.

5. Ability to provide login and logout facility to multiple concurrent users (this will be a multi user application).

6. Ability to authenticate and provide confined view to the user as per permitted privileges.



96

7. Single-Sign On (SSO) facility

8. Customized view based on the user access levels.

9. Support Unicode compatibility.

10. The proposed system should provide relevant prompts to available commands or actions on every screen.

11. The system should have Instructions for receiving help and for quitting from the system should appear on

every screen.

12. The portal will be compatible with the hardware and software used for this purpose.

13. The system will facilitate the administrator to use pre-defied access levels to assign format of reports at

different levels.

14. The system should have the ability auto populate the relevant parameters of any given parameter once it’s

fed or selected in the form. For Eg. If Release Order Number is generated which is used in a form then all the

related fields on the form, which already persist in the database, should populate automatically.

15. The system must have the ability to generate a unique Release Order number automatically.

16. The system should generate the following physical documents in PDF format and store it in the backend

system and be accessible/ download/print the same on need basis.

a. Indent Letter

b. Release Order generation document in PDF format

c. Release Order closing document with daily lifted depot and quantity details

d. Release Order cancelled document

e. Release Order diversion document

f. Release Order Reimbursement Document

g. Delivery/Issue Planning Sheet

h. Weight Check Memo and M-form

i. Inward Gate Pass

j. outward Gate pass

17. This system must have the ability to determine the current process of the Release Order

18. The system must have the ability to generate separate views based on the User Roles and access rights. The

type of web pages displayed will depend upon the access rights given to them. The System should directly

launch the required page.

19. The system must have the ability to perform analysis reports based on the history data and should perform

and make predictions in advance accordingly.

20. The system must have the ability to automate information regarding inbound and outbound trucks and the

quantities that they are carrying.

21. The system must have the ability to update stocks on daily basis.

22. The system must have the ability to maintain record of the transactions pertaining to Release Order based

on the Quantity lifted.

23. The system must have the ability to provide the reports based on the Scheme wise and commodity wise

based on the State Agency/Party.

24. The system must have the ability provide required information to the State Agencies and Parties.

25. The system must have ability to generate notifications against delay in the Release order operations.

26. The system must have the ability to maintain audit trail and keep track of each other’s activities and actions

being performed within the system.



97

27. The system must be able to provide search the database according to the search as per the criteria specified

by the user.

28. The system must have the ability to generate progress reports statements for the selected period (i.e Daily,

Weekly, Monthly and Yearly etc).

29. The system must have the ability to generate progressive reports.

30. The system must have the ability to capture the transactional data for weighbridge from Weighbridge

software.

31. The system must have the ability to print the physical document through portal.

32. The system must have the ability to send print out report in pre-defined format.

33. The system must have the ability to enter, update the information of parties / State Agencies details on

need basis.

34. The system shall utilize the already available information either from Release Order or access it from the

external applications.

4.2.3.2 USER INTERFACE REQUIREMENTS The users from different stakeholders also can access the Release Order Portal online using any web browser. Only the registered users can access the portal based on the access rights and user credentials. The proposed Portal should meet global standards in best practices, design and functionality. The portal should comply with the following standards

Guidelines for Indian Government websites MDDS – Demographic Metadata and data standards Localization standards W3C standards level 2 The portal should be accessible and operational from web enabled devices like Laptops, tablets and smart

phones etc.

Connectivity Requirements to access the application

• To access the Release Order portal, internet connectivity will be needed at both server side as well as client side.

• Communication between the systems is mandatory for data exchange between the Release Order applications and the external applications and vice versa.

• SMS Gateway Server Along with this, the application should have the connectivity to the portal will interact with the SMS Gateway server to push SMS to different stakeholders

• Email servers to send the automated emails generated from the system to various stakeholders of the system.

• Connectivity to the external applications



98

Below are the user interfaces for Release Order application:

Figure 15: Login Page

Figure 16: Dashboard



99

Figure 17: State Wise Allocation Page



100

Figure 18: Add New Revenue District Wise Allocation Page



101

Figure 19: Update Revenue District Wise Allocation Page



102

Figure 20: Generate Indent



103

Figure 21: Indent Approval

Figure 22: Make Payment



104

Figure 23: Make Offline Payment



105

Figure 24: Pending for FAP Approval



106

Figure 25: Approve Indent by Sales



107

Figure 26: Release Order Creation



108

Figure 27: Release Order Approval



109

Figure 28: Gate Entry Token No.



110

Figure 29: Inflow Token No.



111

Figure 30: Weighbridge - Loaded Truck (Inflow)



112

Figure 31: Unit/Shed In-charge (Inflow)



113

Figure 32: Generate Gate Pass (Exit)



114

Figure 33: Empty Truck (Inflow)



115

Figure 34: Gate Exit (Inflow)



116

Figure 35: Empty Vehicle (Outflow)

Figure 36: Generate Token



117

Figure 37: Gate Exit Loaded Truck



118

Figure 38: Depot Manager Review & Approval



119

Figure 39: RO Diversion



120

Figure 40: RO Extension



121

Figure 41: NCDEX Release Order Digitization



122

Figure 42: NCDEX RO Approval



123

Figure 43: FAP Verification



124

Figure 44: Upgrade/Downgrade

Figure 45: Gain/Loss



125

Below are the Reports:

Figure 46: Daily Deposit

Figure 47: FAP Approval

Figure 48: Gate Operator Inflow



126

Figure 49: Gate Operator Outflow

Figure 50: Indent Approver

Figure 51: Area Sales Manager Report



127

Figure 52: Indent Report

Figure 53: Release Order between Dates

Figure 54: Release Order Approver



128

Figure 55: Release Order Creator

Figure 56: Scheme Commodity Wise Issue



129

Figure 57: Scheme Commodity Wise Issue Summary

Figure 58: Scheme Wise Issue



130

Figure 59: Issues off take

Figure 60: Statement of Issue



131

4.2.3.3 GENERAL REQUIREMENTS This section talks about the general (non functional) requirements for the proposed Release Order application.

1. User Rights and Security Management

Control all the authorized users with their assigned rights and only authorized users can login to the

portal and perform the tasks that the administrator of the portal has allowed from menu-level up to the

button level (add, edit, delete, print, post and view etc.)

Authentication of a user to a secure Web site via the Secure Sockets Layer (SSL) protocol with 128 bits

encryption technique.

Access level of each user shall be defined at the time of creating the user.

2. Performance

Background processes, reporting, data loading, data integrity checking, data backup operations etc

should not take a toll on the performance of the system.

System should perform optimally during normal and peak workloads.

The system must be designed for less than 1% downtime at normal load.

3. Operations, Backup and Recovery

Mechanisms and techniques to must be devised to guard against unintentional loss of data. If necessary,

full data recovery must be made possible as and when required.

4. The system should have an emergency / contingency plan during failures.

5. Online Monitoring and Logging

For the purpose of trouble shooting and performance analysis, authorized members activity log

mechanism must be incorporated in the system.

The system must be able to identify and reveal which individual has modified, added or deleted any data

within any part of the system. This feature generates a comprehensive log of all actions under taken by

various users. This trail ensures all information in the system is secure and can be used for accountability

and proper monitoring of the system.

4.2.4 DATABASE REQUIREMENTS

A Release Order database is responsible for storing the data pertaining to release order application. Release Order application uses the MS SQL as a backend system

Following are the identified requirements to create the Database for Release Order Application

4.2.4.1 DETERMINE THE TABLES

Following are the proposed design guidelines to generate the tables for the Release Order application.

Table should not contain duplicate information, and information should not be duplicated between tables (e.g. Store the user details name, in only one table and can be accessed from other tables based on user id key).



132

When each piece of information is stored in only one table, application shall update it in one place. This is more efficient, and also eliminates the possibility of duplicate entries that contain different information.

Design tables without redundant data. Choose appropriate data types for fields. It saves not only space in database and also handles the data

validation checks. Create indexes for fields you sort, join, or set criteria for faster retrieval.

4.2.4.2 DETERMINE THE FIELDS YOU NEED IN THE TABLES

Once the tables are identified the fields required can be determined. When sketching out the fields for each table, keep following tips in mind:

Relate each field directly to the table. Determine the data types and sizes for the identified fields. Don't include derived or calculated data (data that is the result of an expression). Include only the specific information you need.

4.2.4.3 IDENTIFY FIELDS WITH UNIQUE VALUES

There are three kinds of primary keys that can be defined:

AutoNumber primary keys - An AutoNumber field can be set to automatically enter a sequential number as each record is added to the table. Designating such a field as the primary key for a table is the simplest way to create a primary key.

Single-field primary keys - If you have a field that contains unique and not null values such as unique serial numbers or part numbers, you can designate that field as the primary key. The primary key field should not allow the NULL values.

Multiple-field primary keys - In situations where you can't guarantee the uniqueness of any single field, you may be able to designate two or more fields as the primary key. The most common situation where this arises is in the table used to relate two other tables in a many-to-many relationship

4.2.4.4 NORMALIZATION

Normalization is a complex process with many specific rules and different levels intensity. In its full definition, normalization is the process of discarding repeating groups, minimizing redundancy. In simple terms, the rules for normalization can be summed up in a single phrase: "Each attribute (column) must be a fact about the key, the whole key, and nothing but the key." Said another way, each table should describe only one type of entity (such as a release order, commodity, or scheme). Some normalization benefits are:

Data integrity (because there is no redundant, neglected data). Optimized queries (because normalized tables produce rapid, efficient joins). Faster index creation and sorting (because the tables have fewer columns). Faster UPDATE performance (because there are fewer indexes per table). Improved concurrency resolution (because table locks will affect less data).

http://www.databasedev.co.uk/what_is_a_key.html



133

4.2.4.5 DETERMINE THE RELATIONSHIPS BETWEEN TABLES

Once the tables and primary key fields are identified, the related information can place together in meaningful ways.

To do this, define relationships between tables. Relationship is an association between common fields (columns) in two tables. A relationship works by matching data in key fields. In most cases, these matching fields are the primary key from one table, which provides a unique identifier for each record, and a foreign key in the other table.

Relationships between tables are grouped into 4 groups:

o One-to-one (1:1) - each record in Table A can have only one matching record in Table B, and each record in Table B can have only one matching record in Table A. This type of relationship is not common and it is very rarely used in database systems, but it can be very useful way to link two tables together. The information related in this way could be in one table. However, you might use a one-to-one relationship to divide a table with many fields in order to isolate part of a table for security reasons, or to store information that applies only to a subset of the main table, or for efficient use of space. A one-to-one relationship is created if both of the related fields are primary keys or have unique indexes.

o One-to-many (1:M) - is the most common type of relationship and it is used to relate one record in a table with many records in another table. In a one-to-many relationship, a record (parent) in Table A can have many matching records (children) in Table B, but a record (child) in Table B has only one matching record (parent) in Table A. This kind of relationship is created if only one of the related fields is a primary key or has a unique index.

o Many-to-one (M:1) - is used to relate many records in a table with only one (single) record in another table. It is often called the lookup table relationship. Normally, this kind of relationship is not based on a primary key field in either table. Although in theory this relationship is one-to-one, it is known as many-to-one because it does not use a primary key field for the link, and many records from the primary table link to a single record in another table.

o Many-to-many (M:M) - is used to relate many records in a table with many records in another table. A record (parent) in Table A can have many matching records (children) in Table B, and a record (child) in Table B can have many matching records (parents) in Table A. It is the hardest relationship to understand and it is not correct. By breaking it into two one-to-many relationships and creating a new (junction/link) table to stand between the two existing tables (e.g. whose primary key may consist of two fields - the foreign keys from both tables A and B) will enable correct and appropriate relationship setting. A many-to-many relationship is really two one-to-many relationships with a junction/link table.

4.2.4.6 CREATE MASTERS DATA AND BASIC DATA TO RUN THE APPLICATION

Develop the scripts to have the basic data to run the application like (users, schemes, party names, commodities etc) which can be done initially for test environment and can be replicate it to production environment.

Master Data

o Allocation Masters

o Scheme Masters

o Commodity Masters

o FCI District vs Revenue District Mapping Masters



134

o Location wise Project Stakeholder Masters

Head Office

Zonal

Regional/State

FCI District

Depot

User Data

Transactional Data

4.2.4.7 IDENTIFY SHARING FIELDS

To check the external application schema including the tables fields and relationships

Identify the data exchange fields and formats

Design the scheme accordingly

4.2.4.8 BACKUP & MAINTENANCE

The application should take the backups to avoid the loss of the data in case of system failure

1. Data backup – daily – full/Incremental



135

4.3 BEHAVIORAL REQUIREMENTS – SYSTEM LEVEL

4.3.1 USE CASE VIEW

4.3.1.1 RELEASE ORDER PROCESS

ACTORS RELEASE ORDER PROCESS STEPS

Ministry CA&PDS

GOI

FCI Regional Office

FCI District Office

FCI Depot Office

FCI Zonal Office

Allocation

State Agencies/

Parties

Indent Generation

Payment Confirmation Depot Assignment

Release Order Creation

Delivery Plan Weighment

Commodity Issue Commodity Lifting

Request Approve/Reject

Request Reimbursement

Request Approve/Reject

30 Days

RO Initiation

RO Generation

RO Execution

RO Extension

RO Reimbursement

RO Diversion

Kill RO

RO Closing

> 30 Days

15 Days

Close RO

Figure 61: Use Case Release Order Process



136

4.3.1.2 RELEASE ORDER INITIATION

ACTORS ACTORSRELEASE ORDER INITIATION

Add state level Allocation Details along with Issue

Price based allocation orders and guidelines

Update the existing State Level Allocation Details

along with Issue Price according to new new

guidelines given by CA,PDS, GOI

Cancel the schemes/allocations if GOI cancel the

scheme/allocations

STATE LEVEL ALLOCATIONS

Add Revenue district wise allocations based on the

details provided by state agencies/parties

Update the existing Revenue District level allocations

with Issue Price according to new guidelines given by

CA,PDS, GOI

Cancel the schemes/allocations if GOI cancel the

scheme/allocations

Generate the Indent with Scheme and

Commodity along with Bank Details

Approve by FCI Accounts section

Make the payment in bank and enter the

Payment Details

Prepare the allocation requirements based on

the demand and map it to actual GOI

allocations

Select the party enter the payment details

into FAP

Validate the payment Details with the Bank

online and Approve and Email/SMS Sent to

the Respective Parties

Validate Actual allocations with Requested

Allocations

Approve

Approve

INDENT GENERATION

INDENT APPROVAL

REVENDUE DISTRICT WISE

ALLOCATIONS

Approved

Indent

Indent

Generation

E Mail

SMS

Reject

Reject

FAP Online

Ministry CA&PDS

GOI / FCI

Regional Office

FCI Regional Office

State Agency /

Party

FCI District Office

Sales Section

FCI District Office

Accounts Section

Verify

Figure 62: Use Case Release Order Initiation



137

4.3.1.3 RELEASE ORDER GENERATION

ACTORS ACTORSRELEASE ORDER GENERATION

Selects the Designated Depot using DCMS

Assigned the Depot based

on Stocks Availability using IRRS

Generate the Release Order

RELEASE ORDER CREATION

Check the Party, Payment and Commodity Details

Approve the Release Order

Digitally Signed Release Order

Yes

Yes

RELASE ORDER APPROVAL

DCMS

IRRS

FCI Sales Section

FCI District

Area Manager

Retrieve Depot

Details ( DB Scripts)

Retrieve Stocks

Details – DB Scripts

FCI Depot


FCI Depot

FCI District Office

Sales Section

Digitally Singed Release

Order is Generated

Reject

Update RO

(DB Scripts)

E Mail

SMS

Email to OfficersSMS to

Officers

Figure 63: Use Case Release Order Generation



138

4.3.1.4 RELEASE ORDER EXECUTION

ACTORS ACTORSRELEASE ORDER EXECUTION

Generate the Delivery

Plan Sheet

Generate the Inward

Gate Pass

Capture the Truck Tare

Weight from Weigh

bridge

IRRS

Depot Manager


Step 1

Step3 Step 8

FCI Depot


FCI Depot

FCI District Office

Sales Section

Updated RO with Lifted

Quantity

Update Stocks

(DB Scripts)

E MailSMS

Email to Officers SMS to Officers

Gate Incharge

Inward

Gate Pass

Delivery

Plan Sheet

Weighbridge

Software

CSV/Serial

Connectivity

Inward Weight

Receipt

Step 2

Unit Incharge

Step 4

Assign and Validate the

Lifted quantity

Capture the Gross

Weight of Truck

Step 6

Step 5 CSV/Serial

Connectivity

Check the lifted Weight

Vs loaded weight on the

Truck

Step 7

Step 8 - Gain/Loss

Quantity Can be adjusted

Continue the RO Execution Steps 1 to Step 9 till all the

quantity against Release Order is lifted

FEAST

Update Stocks

(DB Scripts)

Freeze the lifted Quantity

Aggregate lifted Stocks

On Daily basis

Step 9

Weight Check

Memo

Outward

Gate Pass

Figure 64: Use Case Release Order Execution



139

4.3.1.5 RELEASE ORDER CLOSING & OTHER SCENARIOS

ACTORS ACTORSRELEASE ORDER EXECUTION

Generate the Delivery

Plan Sheet

Generate the Inward

Gate Pass

Capture the Truck Tare

Weight from Weigh

bridge

IRRS

Depot Manager


Step 1

Step3 Step 8

FCI Depot


FCI Depot

FCI District Office

Sales Section

Updated RO with Lifted

Quantity

Update Stocks

(DB Scripts)

E MailSMS

Email to Officers SMS to Officers

Gate Incharge

Inward

Gate Pass

Delivery

Plan Sheet

Weighbridge

Software

CSV/Serial

Connectivity

Inward Weight

Receipt

Step 2

Unit Incharge

Step 4

Assign and Validate the

Lifted quantity

Capture the Gross

Weight of Truck

Step 6

Step 5 CSV/Serial

Connectivity

Check the lifted Weight

Vs loaded weight on the

Truck

Step 7

Step 8 - Gain/Loss

Quantity Can be adjusted

Continue the RO Execution Steps 1 to Step 9 till all the

quantity against Release Order is lifted

FEAST

Update Stocks

(DB Scripts)

Freeze the lifted Quantity

Aggregate lifted Stocks

On Daily basis

Step 9

Weight Check

Memo

Outward

Gate Pass

Figure 65: RO Closing & Other Scenarios

5. NON FUNCTIONAL REQUIREMENTS This section talks about the non functional requirements of the proposed release order application.

5.1 PERFORMANCE REQUIREMENTS Performance is defined as the responsiveness. Release Order Application should manage the user load and response time. The response time for average network connectivity speed should be as follows:

90% of the responses for static web pages should be within 2 seconds. 5-10 second: For user operation on data (for e.g. sorting of data in a column) or (5 to 50 records per page up

to max of 100,000 records) 10-20 second: For user awaiting response from the system upon executing a transaction (for e.g. a

query/update). 1 minute – Unacceptable response time

It would be the key challenge is that its interact with the external applications to perform the Release Order Operations The proposed solution should take care of the application level performance requirement by do the data



140

sync like caching technique. The size of pages should be such that even on low bandwidth internet connections response time should be satisfactory. Following are few guiding principles but not limited to that Releaser Order Application should adhere in order to achieve high performance

Most of the application level logging should be disabled in production code. (Only Critical level logs are maintained in the production environment to improve the performance). In test environment keep all the logs.

Code should be optimized in the performance testing phase before deploying in production environment.

5.2 SAFETY AND SECURITY REQUIREMENTS In order to maintain the highest levels of security and privacy of the data, the following requirements to be considered:

Application and data access strictly as per the user/group/role based access controls and password

protection.

Maintain the access controls based on the user levels.

Password security at operating System level and application level.

Access control and rights and authorization levels.

Provision for digitally sign Release Order to ensure security.

Protection against virus threats, Intruders, Trojans and other security threats.

5.3 SOFTWARE QUALITY ATTRIBUTES

5.3.1 HIGH AVAILABILITY High availability refers to a system or component that is continuously operational for a desirably long length of time.

5.3.1.1 INFRASTRUCTURE LEVEL – NIC To achieve the high availability of following components are to be ensured.

Network elements such as routers, gateways etc. firewalls load balancers/dispatchers

5.3.1.2 SOFTWARE LEVEL Following are proposed guidelines to achieve the high availability of the Release Order application

All file names should be relative Do not hardcode IP addresses Do not bind anything with 'local host' Minimize amount of data saved in 'http session object' Do not use static variables Do not perform write operations on external files



141

5.3.2 SCALABILITY Scalability is the ability of a system, network, or process, to handle growing amount of load in a Release Order Application Following measures of scalability to be consider while developing the proposed Release Order application. Administrative scalability: Number of stakeholder organizations may increase in future Functional scalability: New functionality may be needed to be added Geographic scalability: Extended it to more depots or offices may be added in future Load scalability: Number of users may increase To address the scalability challenge, the modular design will be adopted. Proposed architecture will use Service Oriented Architecture (SOA). Interactions among the various services and integration with the existing application will be achieved using XML open standards. T The proposed solution should adhere to following are few principles in order to achieve scalability

• Make software and layout design highly modular.

• The solution should be developed using layered architecture with components spread across different

architectural layers.

• Make the client component as thin as possible to serve the end user requests in faster and efficient manner.

• In the data layer, to serve the data requests in parallel, multiple instances of database must be deployed.

Based on the load and other parameters, done can plan the clustering of underlying data sources.

• The data archival and purging based on the requirement will also improve the scalability of the application.

5.3.3 INTEROPERABILITY Interoperability is the ability of diverse systems and organizations to work together (interoperate). Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation. The interfaces of Release Order application should be properly exposed to make it interoperable. The proposed architecture of Release Order Application is built around the web services standard and adopts open data exchange standards for interacting with various applications to address the interoperability requirement. Interoperability also means the ability of software to work on different browsers adhering to standards.

• The Release Order Application should follow standard technologies and techniques, data models and

interfaces.

• Meta data and application standards must be taken into account from the inception of the Release

Order Application.

• Vendor-specific extensions to the standard Web technologies (XHTML, HTML, JavaScript) and plug-ins

should be avoided.

• Distributed search of site may use page-level Meta tags, a site map and/or site search tool.

• External interfaces transactions should be logged.



142

• use Web services to integrate with existing applications

• The application should work with most common Operating systems, web browsers, and access devices

like computers, laptops and mobiles.

5.3.4 USABILITY Usability is a quality attribute that assesses how easy user interfaces are to use. The proposed application should be easy to use. Usability is defined by following quality components:

• Learnability - How easy is it for users to accomplish basic tasks the first time they encounter the design?

• Efficiency - Once users have learned the design, how quickly can they perform tasks?

• Memorability -When users return to the design after a period of not using it, how easily can they

reestablish proficiency?

• Errors - How many errors do users make, how severe are these errors, and how easily can they recover

from the errors?

• Satisfaction- Make the application more modular

• Use relative font size so that a user can easily change overall font size from the browser interface.

• Release Order Application should function even with simple JavaScript and CSS.

• Navigability –The user should be able to perform operations without having to navigate through

multiple pages/links – No operation should require more than 4 to 5 clicks.

• Familiarity – The system’s interfaces and navigations should be based on other systems that the users

are familiar with.

Administration – The system should not require any administration tasks at the user level. Interfaces

should be available for administration/setup operations.

Help - The system should provide online help to the end users.

Standards Adherence – The system should adhere to commonly accepted standards of web-design

(such as acceptable size of web pages, small style sheets etc)

5.3.5 EXTENSIBILITY Extensibility refers the ability to add new functionality without requiring major changes to the existing code. Release Order Application should be extensible in the sense that new features can be easily added or plugged-in without any significant changes to the existing system.

• Release Order Application should be extensible to adopt following changes with minimal or no changes

to existing code.

• Providing new workflows.

• Providing new functionality or feature or service.

Following are few guiding principles to be followed but not limited to that Release Order Application should adhere in order to achieve extensibility–



143

• Solution must be developed using Layered architecture

• Solution must follow Object oriented methodology, which inherits extensibility

• User defined attributes

• Business rules

• Configurable parameters

5.3.6 MAINTAINABILITY Software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes. Proposed solution should adhere to the following guidelines for realizing Maintainability

• Software Code must be modular and well documented.

• Avoid Complex Coding: Very complex “spaghetti code” is quite difficult to maintain safely. Hence it should

be avoided.

• Early planning: anticipating what and how programs might be modified at a later stage.

• Modular design: defining subsets and simplifying functionality (i.e., one module performs only one function).

• Object-oriented design: encapsulating both methods and data structures to achieve a higher level of

independence.

• Uniform conventions: facilitating error detection and debugging.

• Naming conventions: providing understandable codes.

o Use of Coding standards, comments, and style enhancing readability of the program.

o Use of Documentation standards

o Use Common tool sets

o Configuration Management

o Proper versioning of the software to be maintained.

• All the artifacts related to the software such as code, SRS, User Manual etc. should be well documented and

self-explanatory for any programmer to understand. Detailed documentation shall be available at each stage

for easy comprehensions of the application system.

• All documents shall be prepared as per the defined documentation standards.

• Backup and recovery policy should be in place for databases. The system administrator shall take regular

back up of the database.

• Configurable parameters

5.3.7 UNIFORMITY OF PARAMETER

To develop a web enabled, work flow based application for Release Order with appropriate linkages with DCMS, FEAST, DCMS, FAP and Weighbridge applications which will enable to have a complete view of the inflow and outflow of the commodities and the stock position in the depot , we have to define some protocols. Existing external applications are running independently and application users are repeatedly entering the

same parameters manually in the applications separately based on data available in physical papers. There are

several ways for applications to exchange data with other applications. We will select any one among CSV, XML

or open format to exchange data. Hence, there is no validation and verification checks for the entered data

since the applications are running independently RO Application will maintain Uniformity of Parameters.



144

Data maintained by external application are different type and format. Standards should be developed to insure

compatibility between applications developed by different vendors, and to allow for reasonable success in

transferring data. The RO Application will produce standards that deal with data communications. The standards

bring uniformity to data communications.

Data standardization is the first step to ensure that your data is able to be shared across the enterprise. This

establishes trustworthy data for use by other applications in the organization. Ideally, such standardization

should be performed during data entry. If, for some reason this is not possible, a comprehensive back end

process is necessary to eliminate any inconsistencies in the data.

For instance: when application will communicate through the FAP application then user has to go for XML data

exchange which is platform and software independent. XML data exchange reduces the over head on the

application due to its nature. Both the vendors will agree on a particular format of the XML to interchange the

data and get the desired result set.

Another example we take of as data exchange between FIST and RO application as WSDL format. WSDL is used

to HTTP protocol to communicate between client and server. WSDL format is widely preferred and can be

generated by the WCF service. WCF service has it on features and more ever is platform and language

independent.

Data exchange will take place in the application based on client and server and request and response based. A

client is going to send the request and getting response from server. The request can be a form of Entity and

response will be in form of Entity so that we can have same data contract between client and server.

In case of weighbridge communication we are going to provide the WCF server to get weighment details. WCF

service will expose by the client and consume by the application to get the weighment details.

Data contract will help to make data standardization by using the provision of SOA (Service oriented

architecture)



145

5.4 USER GROUPS WITH ACCESS LEVELS

The Application users are classified into four levels based on Roles and Responsibilities.

Group Description Access Rights

Administrator - Technical Support Team

Administer and Configure the software

The administrator has full control over the system. He is

responsible for creating groups /users, giving them access

rights, modifying groups / users, creating, editing, and

deleting workflows and archival to CD or Storage Disks.

Full control (Read, delete, view and write privileges) of

each interface.

Report Generation

Database Backup

Change Tracking

User Management

ACRs/Inquiry Reports

Level - 2 FCI Zonal/Regional Officers /District Area Manager

Higher officials of FCI Department

User management for Level 3 and 4 Groups within

Judiciary

Application Progress Monitoring and Review

Verify/ Approval/Reject the Requests

Digitally sign the approval Records

State Agency/Party User management for Level 3 and 4 Groups within

Judiciary

Allocation and Indent Generation Reports

Release Order Progress monitoring and Tracking

To generate the Extension/Diversion/Reimbursement

Requests

Level - 3 FCI/ State Agency District Level Officers

FCI District Officer – Sales

User management for Level 4 Group within Judiciary

Report generating facilities

Release Order Operations configuration

Read Write privileges to a few exceptional interfaces to

handle the Release Order

Diversion/Reimbursement/Cancellation /Extension

Requests

Release Order Creation Operations

Release Order Execution monitoring

FCI District Officer – Accounts

User management for Level 4 Group within Judiciary

Indent Verification and Approval

Release Order Progress monitoring and tracking Reports

FCI Depot Manager Release Order Execution Reports

Release Order Execution Step Configuration



146

Group Description Access Rights

State Agency/ Party Officer

To track and monitor the Release Order Execution Reports

Verify/Approve/Reject the Requests

Level – 4 Operators

Data Entry Operators

Read/write (as per the group/security policy) for all

Interfaces.

Access to the input forms to enter the required Data

5.5 APPLICATION ENVIRONMENT

5.5.1 CLIENT ENVIRONMENT Release Order client is a web application and runs on any standard browser, so the various details about the operating environment is unimportant and hidden from the end user. End users can use the application from a modern internet browser such as Firefox, Chrome, and Internet Explorer. However, it’s recommending to have a following environment for better visibility and navigation flow and to meet the proposed SLAs.

5.5.1.1 OPERATING SYSTEM

Any Standard Operation System like Windows, Linux or Unix Flavor

5.5.1.2 SYSTEM CONFIGURATION

1. Intel based Pentium IV workstations

2. RAM: 2GB or More

3. HDD: 50 GB or More

4. Accessories

a. Keyboard, Monitor and Mouse

b. Printer – (Optional for printing the Documents & Reports )

5.5.1.3 SUPPORTED BROWSERS Any standard browser is supports but it’s recommended to have following browsers for better look and fell and navigation flow

1. Internet Explorer 10.0 or up to the existing higher version as on deployment date

2. Google Chrome 17.0 or higher

3. Mozilla Firefox 30.0 or higher

5.5.2 DEVELOPMENT ENVIRONMENT

5.5.2.1 OPERATING SYSTEM

Operating System: Windows 7 or above



147

5.5.2.2 SYSTEM CONFIGURATION

1. Intel dual core with 2.02 GHz

2. RAM: 4GB or More

3. HDD: 300 GB or More

4. Accessories


5.5.2.3 SOFTWARE

Front end : ASP.net, html, JavaScript, CSS

Back end Database : MS SQL 2008

Technology used : Visual studio 2008 or Above

Language used : c sharp (c#).

Version Control: VSS

5.5.3 DEPLOYMENT ENVIRONMENT Following is the system configuration to deploy the Release Order application in production environment System Configuration

1. Intel Multi-core processor or better Quad-core processor

2. RAM: 16 GB or More

a. 4 GB available for IIS server installation and initial usage, plus room for perpetual growth

b. 5 GB available for web server installation, plus room for perpetual growth

c. 5 GB available for SQL Server installation and initial usage, plus room for perpetual growth

d. 2 GB buffer for Operation System processes

3. HDD: 1 TB or More

a. 500 GB for Database

b. 200 GB IIS Server

c. 300 GB for OS and others

4. Accessories


Software Operating system: Windows 2008 Server or Above

Back end Database: MS SQL 2008

Web Server: IIS 7.0 or Above.



148

5.6 IMPLEMENTATION APPROACH

This section provides the project Release Order application implementation approach by the eCentric to execute the project

5.6.1 IMPLEMENTATION STRATEGY

System Analysis o Study of Existing Release Order Operations/Reverse Engineering o Study the External applications that use the proposed Release Order Application. o Study the existing infrastructure and communication mechanism. o Perform Gap Analysis

Prepare the System Regiment Specification Document o Review and Sign-off

Prepare the Design Document

Application Development o Develop application prototype o Implement the Solution at Pilot Location o Customize the Application o Design Finalization - based on the pilot study outcomes the solution would be designed and the

proper documentation is to be drafted for the proposed solution. o Sign-off the Design document

Roll out o Create integration and system test plan and test cases o Implement the application functionality o Application Components Integration o Hardware Components Integration o System Integration includes both hardware and software components integration o Create integration and system test plan and test cases

Unit & Integration Testing o Execute the test cases and fix the bugs o Unit Testing o Integration Testing

User Acceptance Test o Deploy the application at UAT o Execute the UAT Test Cases o Fix the bugs

Application Deployment o Setup the application environment o Deploy the application

System Demonstration and Application Training o The installed application would be demonstrated to the FCI officials and take the feedback and

training would be conducted

Enhancements based on the suggestions o Customize the application based on the suggestion from the FCI officials if needful.

System Maintenance and Support o Make sure that system perform the operations round the clock without fail.



149

5.6.2 EXECUTION PLAN

S.No. Phase Activity M1

M2

M3

M4

M5

M6

M7

M8

M9

M 10

M 11

M 12

1 I SRS including linkage with Weighbridge & Other Applications, data standardization

2 II System Design, Database Design & Test Plan

3 III Application Development and integration with existing applications & Test cases

4 IV Application Testing along with linkage with existing applications, Test reports

5 V Security Audit & Application Deployment

6 VI Training and Roll Out

7 VII Implementation Support, Feature enhancements, Application maintenance and handing over of application

5.7 CAPACITY BUILDING & USER TRAINING Following User Manuals and Guides for system personnel and end users would be provided in both hard copies and electronic form based on the user levels System Administrators and System users

Administration guide for configuring and managing the Release Order application Administration guide for web application.



150

6. APPENDIX A - DATA DICTIONARY

Figure 66: Data Dictionary



151

7. APPENDIX B - GROUP LOG

Third User Group Review meeting held on 15/07/2014 at FCI Head Quarters to discuss on FAP integration.

Second User Group Review meeting at FCI Head Quarters on 01/07/2014 on Release Order processes.

First User Group Review meeting at FCI Head Quarters on 05/06/2014 on Release Order Processes.

Field Study at FCI stakeholder locations.

Discussions with Project stakeholder departments (FCI and NIC)

Field Survey & Feedback Reports

External Applications study with NIC and FCI officials

Physical Ledgers/Forms

8. APPENDIX C - REFERENCE DOCUMENTS & PHYSICAL COPIES

S.No Description of the Document Document Name

1. DPR Document (Refer to SRS Version 1.5) DPR

2. Field Visit Reports (Refer to SRS Version 1.5) FCI Mayapuri Survey

3. Release Order Operations Study & Discussion Points (Refer to SRS Version 1.5)

RO Operations Discussion

4. FAP Integration & Discussion Points (Refer to SRS Version 1.5)

FAP Study Report

5. Weighbridge Study, Integration Solution and Discussion Points (Refer to SRS Version 1.5)

Weighbridge Integration

6. Release Order Physical Documents (Refer to SRS Version 1.5) Sample

7. Release Order Physical Documents (Refer to SRS Version 1.5) RO Printed

8. Modification History History



152

Modification History

S.No. Page

No.

(if

any

in

Ver.

1.5)

Initial Text (as in SRS Version 1.5) Page

No.

(if

any

in

Ver.

1.6)

Revised text (as in SRS Version

1.6)

Remarks

1 14 Further, commodities allocated FCI Revenue District wise.

14 Further, commodities allocated FCI Revenue District wise by respective State Govt.

Sales

division’s

feedback

2 14 State Agency/Party make payments to Food Corporation of India for allotted quantity based on the Central issue prices.

14 State Agency/Party make payments to Food Corporation of India for allotted quantity based on the Central issue prices (state wise, scheme wise, crop year & commodity) / issue price(OMSS & Commercial) as decided by Govt. of India.

Sales

division’s

feedback

3 14 Diversion of Release Order – identification of alternate FCI depots in case of the initially identified depot runs out of stock.

14 Diversion of Release Order – identification of alternate FCI depots in case of the initially identified depot runs out of stock, at the request of State Govt. or any other operational/ natural exigencies.

Sales

division’s

feedback

4 14 Point no. 4 was

State Agency/Party make payments

to Food Corporation of India for

allotted quantity based on the

Central issue prices.

14 Now point no. 4 is

State Agency/Party make

payments to Food Corporation

of India for allotted quantity

based on the Central issue

prices (state wise, scheme wise,

crop year & commodity) / issue

price(OMSS & Commercial) as

decided by Govt. of India.

Based on

MOM


Diversion of Release Order – identification of alternate FCI depots in case of the initially identified depot runs out of stock.


Diversion of Release Order –

identification of alternate FCI

depots in case of the initially

identified depot runs out of

stock, at the request of State

Govt. or any other operational/

natural exigencies.

Based on

MOM



153

6 15 Existing Release Order is not being generated in predefined standard format. Most of the States uses their customized format to generate the Release Order.

15 Existing Release Order is not being generated in predefined standard format. Most of the FCI District Offices use their customized format to generate the Release Order.

Sales

division’s

feedback


All the weighbridge vendors shall provide the necessary data and linkages, based on standards as finalized by FCI (preferably by XML/CSV).


RO Application will define the protocol so that all weighbridge system shall provide the necessary data and linkages, based on standards as finalized by FCI (preferably by XML/CSV).

Based on

MOM


All the financial transactions including (payments verification and taxes and penalties etc.,) would be taken care in FAP. Release Order application shall maintain only the final status provided by FAP.


All the financial transactions would be routed through FAP. Release Order application shall maintain only the final status provided by FAP.

Based on

MOM

9 28 28 Scheme Table has been taken from DISFM.

Sales

division’s

feedback

10 29-30 Monthly - 50 Days 30 Monthly - 30 days or as per GOI order

Sales

division’s

feedback

11 29-30 Need Basis – Generally 50 days or as per the Govt, Order

31 As per the GOI order. Sales

division’s

feedback

12 29-30 Monthly/Quarterly - 50 Days

31 Quarterly – 115 days Sales

division’s

feedback

13 29-30 Monthly – 50 Days Except in Year Closing months

31 Quarterly – 115 days Sales

division’s

feedback

14 29-30 Monthly - 50 Days 31 Monthly - 50 days or as per GOI order

Sales

division’s

feedback



154

15 29-30 Quarterly 31 Quarterly – as per GOI order Sales

division’s

feedback

16 29-30 31 AGPLM/NPAG/SABLA Is one row as SABALA only.

Sales

division’s

feedback

17 29-30 To clear the surplus stocks 32 As per DO, FCI or Release Order Sales

division’s

feedback

18 29-30 32 Annapurna Scheme is added as active Scheme

Sales

division’s

feedback

19 33 Monthly once between specific time interval

34 As per indent by State Govt. Sales

division’s

feedback

20 46 FCI district officer will extend the RO up to 7 days

48 FCI district office will extend the RO up to the validity period given by GOI.

Sales

division’s

feedback

21 46 Regional Office can extend the RO up to 15 days

48 After the expiry of validity period given by GOI, Regional Office can extend the RO up to 15 days and thereafter, Zonal Office can extend it for another 15 days.

Sales

division’s

feedback

22 46 Ministry and Headquarters can extend the RO for no limit

48 Ministry can extend the RO for no limit

Sales

division’s

feedback

23 46 Extension Request for 7 working days by District Area Manager excess storage amount can be deposited within 2 days.

48 Extension Request as provided in the guidelines in vogue of OMSS (D).

Sales

division’s

feedback

24 46 Point no. 4 is deleted Extension Request for 15 working days can be done by the Regional Office.

Sales

division’s

feedback


User can edit only those allocations

for which revenue district

allocation has not been happened.


User can edit allocations and excess off take if any will be flagged in case allocation has been reduced.

Based on

MOM



155

26 57 Point no. 2 was deleted

Allocation would be done only for one state at a time.

Based on

MOM

27 58 Point no. 1 was deleted. Those revenue district allocation can be modified for which indent has not been created.

Based on

MOM

28 58 Point no. 2 was deleted

Allocation would be done for one state at a time

Based on

MOM

29 58 Point no. 7 was Allocation should also be done in multiple revenue districts.


Allocation should be segregated

across the revenue districts.

Based on

MOM

30 CPI/Rate CPI/Issue Price Based on

MOM

31 59 Point no. 6 Formula of Quantity was Available Quantity= Total Allocation – Total Quantity of Generated Indent

61 Now point no. 6 Formula of Quantity is

Quantity Available for

Indenting/Off take = Total

Allocation – Total Quantity

Indented

Based on

MOM

32 59 Point no. 6 Formula of Cost was Cost of Food Grains = Quantity * CIP/Rate

61 Now point no. 6 Formula of Cost is

Cost of Food Grains = (Quantity

* CIP/issue price) + Applicable

Taxes

Based on

MOM

33 60 Point no. 10 Formula of Indent Amount was Indent Amount= Cost of Food Grains + Tax Cost – Deductions Cost

61 Now Point no. 10 Formula of Indent Amount is

Indent Amount= Cost of Food Grains + Tax Cost – Deductions (if any)

Based on

MOM

34 63 Details of “FAP Approve / Reject” section was In FAP Approve / Reject module user will be provided with below details

65 Details of “FAP Approve / Reject” section is Before approval FAP user has to enter receipt No. and document No. from FAP module to RO module in the relevant fields in FAP Approval screen. In this screen, FAP user will be provided with the following fields

Based on

MOM

35 64 Point no. 1 was deleted Document number and Receipt

Based on



156

Number details will be fetch from FAP Application. It will be happened through a service.

MOM

36 64 Point no. 2 was User can upload Receipt in PDF Format.

66 Now point no. 2 is FAP User can upload Receipt in PDF Format.

Based on

MOM

37 64 Point no. 3 was If user will get payment details from FAP Application user will approve payment else user will reject payment.

66 Now point no. 3 is FAP user will verify and approve the payment details. In case payment is not available then FAP user has option to reject the indent with rejection remarks.

Based on

MOM

39 64 Requirement #5 was Application should have ability to ability to approve or reject the current indent details by Area Sales Manager.

66 Now Requirement #5 is Sales division can approve or reject the current indent details vis-à-vis the amount deposited and the quantity indented.

Based on

MOM

40 64 Indent Status 66 Indent Status (FAP Approved/Rejected)

Based on

MOM

41 66 FAP Approved Indent No. 68 Commercial/Sales Approved Indent No.

Based on

MOM

42 66 Point No. 3 was Release Order date will be less or equal to Today date.

68 Now Point no. 3 is Release Order date will be Today’s date.

Based on

MOM

43 67 FAP Approved Indent No. 68 Commercial/Sales Approved Indent No.

Based on

MOM

44 67 Point no. 5 & 6 is merged.

69 Based on

MOM

45 67 Point no. 7 was Only one commodity can be added in one Release Order.

69 Now point no. 7 is as 6 Only one commodity/scheme can be added in one Release Order.

Based on

MOM

46 67 Point no. 8 was Issued quantity of Release Order can’t be more than Available Indenter Quantity.

69 Now point no. 8 is as 7 Quantity of Release Order can’t be more than approved Indented Quantity.

Based on

MOM

47 67 Point no 9 was Multiple “Release Orders” can be created against one Indent if Indenter Quantity available. After creating one Release Order, when user will create another Revenue Release Order against same Indent,

69 Now point no. 9 is as 8 Multiple “Release Orders” can be created against one approved Indented Quantity. After creating one Release Order, when user will create another Release Order against

Based on

MOM



157

user can allocate remaining quantity only.

same Indent, Release order can be issued for remaining quantity only.

48 67 Commodity Amount = (CIP/Rate * Issued Quantity)

69 Commodity Cost = (CIP/Issue Price * Issued Quantity)

Based on

MOM

49 67 Total Release Order Cost = (Commodity Amount + Tax/Vat/Others Charges - Deductions)

69 Total Release Order Cost = (Commodity Cost + Applicable Tax/Vat/Others Charges - Deductions)

Based on

MOM

50 68 Point no. 1 was User able to generate the physical copy of the Release Order with Digital Signature in Approved tab.

69 Now point no. is User able to generate the physical copy of the Release Order with Digital Signature which is mandatory.

Based on

MOM

51 68 Point no. 2 was Release Order Validity date will be greater than to Today date

70 Now point no. 2 is Release Order Validity date will be greater than to Today date and should not be more than lifting duration.

Based on

MOM

52 68 Point no. 4 is deleted. Digital Signature will be in .JPG Format only.

Based on

MOM

53 Inflow Gate Entry - Empty Truck

Gate Entry - Loaded Truck

Based on

MOM

54 70 Point no. 4 was Duplicate Commodity details will not be added again.

72 Single Commodity details will be allowed.

Based on

MOM

55 72 Point no. 3 is deleted Exit Gate Pass No. should be validated with generated Gate Pass No.

Based on

MOM

56 76 Point added In case of Rail Siding Depot, internal movement/rail movement, truck shall be tare weight every time.

Based on

MOM

57 75 Generate Gate Exit Pass section is deleted.

Based on

MOM

58 Special Order Date Is deleted.

Based on

MOM

59 Special Arrival Date Special Arrival Date & Time

Based on

MOM



158

60 Special Release Date Special Release Date & Time Based on

MOM

61 77 Special Order Date should be less than or equal to today’s date.

78 Special Indent Date should be less than or equal to today’s date.

Based on

MOM

62 77 Special Dispatch Date should be greater than or equal to today’s date.

78 Special Dispatch/Release Date should be greater than or equal to today’s date.

Based on

MOM

63 77 Point no. 3 is deleted Duplicate Commodity Received details will not be added again.

Based on

MOM

64 78 Gate Exit – Empty Truck 78 Gate Exit – Loaded Truck/ Empty Truck (in case of exceptions)

Based on

MOM

65 78 Depot Id 78 Depot Name Based on

MOM

66 Entry Date should be current date. Entry Date and time should be current.

Based on

MOM

67 78 Generate physical copy 79 print physical copy Based on

MOM

68 Entry Date Entry Date and Time Based on

MOM

69 79 New point added A valid token number is one as long as the truck is within the Depot premises.

Based on

MOM

70 Token Number must be a valid token number.

Token Number to be printed must be a valid token number

Based on

MOM

71 In Inflow Gate Exit – Empty Truck

Now Gate Exit – Loaded Truck

Based on

MOM

72 Weighbridge Serial No. Weighbridge Identification No. Based on

MOM

73 80 80 New point added A valid token number is one as long as the truck is within the Depot premises

Based on

MOM

74 80 80 New Point added Truck Number will be fed in running order without space.

Based on

MOM



159

75 All the weighment details should come from the Open xml data format.

80 All the weighment details should come from the Open xml data format. Where ever weighbridges do not have a capability to exchange data in open data format, the weighment details shall be manually fed at weighbridge/gate.

Based on

MOM

76 Issuable? Issuable/Non Issuable Based on

MOM

77 Bag Type Bag Type (BT/SBT/PP) Based on

MOM

78 In Out Flow Commodity Unloaded

Commodity Loaded

Based on

MOM

79 82 Point no. 3 was Duplicate Commodity Unloaded details will not be added.

83 Now Point no. 3 is Duplicate Commodity details will not be added.

Based on

MOM

80 83 Commodity Unloaded 83 Commodity Loaded Based on

MOM

81 83 No. of Bags Unloaded 83 No. of Bags Loaded Based on

MOM

82 84 New point added Truck Number will be fed in running order without space

Based on

MOM

83 84 New point added Gate pass shall be prepared/ generated by Unit/Shed In-charge.

Based on

MOM

84 83 Application should have ability to add the commodity received by Depot manager.

84 Application should have ability to take action on Release Order/Dispatch Order in case of exigencies like Initiation of RO Diversion, Closing of RO, Re-weighment etc..

Based on

MOM

85 83 Release Order No should disappear after taking action by depot manager from the grid.

84 The list of Release Orders against which action has already been taken shall not be available to the depot manager.

Based on

MOM

86 86 RO Amount 87 Deposited Amount Based on

MOM

87 86 RO Extension Status 87 RO Extension Status and Authority

Based on



160

MOM

88 86 Extend RO Approval Date 87 Extend RO Approval Date and Authority

Based on

MOM

89 88 88 For PDS/OWS and OMSS business rule is added

Based on

MOM

90 89 Point no. 2 & 3 is deleted. Based on

MOM

91 89 Point no. 4 was RO Extension Validity Date will be greater than to Today date.

90 Now point no. 4 is Validity will be defined as per MTF

Based on

MOM

92 89 Upgrade/Downgrade or gain/loss 90 Upgrade/Downgrade Based on

MOM

93 92 93 New point is added Digital signature will be mandatory for NCDEX RO.

Based on

MOM

94 92 93 New point is added No Payment verification from FAP Application is required as RO is already generated.

Based on

MOM