Thick Client to Thin Client Porting

Med Inventory

Med Inventory

Thick Client to Thin Client Porting

System Requirement Specifications

1.0

Table of Contents

1.Document Information

2.Introduction

3.Technology Selection

4.Requirements Definition

4.1.Master Screens:

4.2.Receipts

4.3.Receipt Documentation / Data Storage

4.4.Issues.

4.5.Reports.

4.6.Processes

4.7.Utilities

4.8.System Administration Tasks

5.Technical Inputs to Developers

6.System Requirements

7.Deliverables

8.Other Terms and Conditions

1.Document Information

2.Introduction

Med Inventory is an inventory management system for Govt hospitals. Major transactions are Receipt and Issue. Rest are controlled corrections of entries, report generation and communication with external agencies.

This software currently has been coded in Visual Basic 6.0. This needs to be ported to a web based online multiuser system.

3.Technology Selection

The desired system is to be based in .Net technologies. Below mentioned tool stack is to be utilized for the development of the web based frontend and backend. Latest versions of all of the below need to be utilized wherever applicable.

Browser Based Frontend/UI:

• Angular JS
• ASP.Net MVC Core
• CSS
• Java Scripting

Backend/Database:

• MySQL

4.Requirements Definition

Below sections detail the functionality of the proposed system.

4.1.Master Screens:

Catalogue Master. It is master list of Items. It contains Item Name and alias name (Short Name), Accounting Unit, Procurement Mode and certain other inputs specific to govt method of accounting.

Item Master. It is sub set of catalogue Master wherein further details of items like Qty, reference to manual Ledger i.e. Ledger No and Page No, Current Stock Balance and links to other fields of Catalogue Master are stored. Data of some fields remains static while few are updated dynamically based on transactions.

Other Masters. Include Accounting Unit Master, Sources of Procurement, Suppliers and entities to whom items are issued e.g. Wards etc. These masters rarely need addition or updating.

4.2.Receipts

Are of three types:

1. Indents. These are from Govt Depots against indents raised by the system. Item are related through a Field called Vocab No, which is primary key of Depot.
2. Local Purchase. For this there is elaborate process (procurement module) where tendering, comparison of quotation by vendors and then Supply Orders are generated after detailed process of vetting. For this process also indents are raised but in different format with some other information. Procurement module is out of the scope of current requirement. Only receipt entries are to be incorporated. Such receipts may be manually, against Supply Orders generated through system or Bar Code.
3. Other Sources. Items may be received from other hospitals where there are surpluses and are likely to expire before consumption. These are directly received without any previous indenting.

4.3.Receipt Documentation / Data Storage

Following data is stored and accordingly reports are generated.

4.3.1.GRN Master and Details. GRN Master contains one record per Receipt Entry with details of Supplier, Date of Receipt, Supplier Voucher No etc and GRN Details contains details of Items like Qty Received, manufacturer, Date of Manufacturing / Expiry and Batch No and rate and taxes information.

4.3.2.Stock Ledger. It contains one entry per receipt per item. Has columns Receipt, Issue and Balance Qty.

4.4.Issues.

Items are issued to Wards and Patients

Issue Documentation / Data Storage.

Following data is stored and accordingly reports are generated.

4.4.1.Issue to Wards.
Issue is made either manually or against Indents made on line. Data is Stored in a Master and Details Table. Master Table contains details of ward, Voucher No, Date of Issue while Details table contains Items issued i.e. Qty, Batch, Manufacturing and Expiry date etc. Accordingly qty from respective GRN Details are reduced and overall stock balance is updated in Item Master. The issue entries may be manual or through Bar Code process.

4.4.2.Issue to patients
Same as above for wards, except that data is stored in separate set of two tables and issues entries are manual.

4.5.Reports.

Following reports are generated. Formats of all Reports are standard and shall be given by us. All the below reports shall come with options to print, save in .PDF format, in Excel/spreadsheet or xml file, as well as email them to users.

4.5.1.Receipt Voucher as per details stored in GRN Master and Details

4.5.2.Issue Voucher for wards as per Master and Details

4.5.3.Stock Ledger for any item for selected period giving receipt and issue entries in chronological order.

4.5.4.List of items nearing expiry in selected period

4.5.5.Stock Status at any point of time.

4.5.6.Expense Voucher For a given Month giving summary of Items Issued during selected month

4.5.7.Issues. Date wise, Ward Wise or Item Wise issues for a selected period.

4.5.8.email Facility for emails to suppliers.

4.6.Processes

Following processes are required.

Month End Process. On the last day of each month, Month end process is executed which compiles items issued during the month to Wards and Patients and make an aggregate entry in Stock Ledger, one record per item and balance Qty is computed.

Indent to Depot in Printed, XML or Excel file.

4.7.Utilities

Following utility features are required to be developed:-

4.7.1.Changing Voucher No or Date

4.7.2.Re-computationof Ledgers – in case of any variations.

4.7.3.Changes to Batch Details, Manufacturing / Expiry Date etc.

4.8.System Administration Tasks

These are performed through an Admin Module. It involves:-

4.8.1.Creation of Users and permitting / revoking rights to use one or more modules.

4.8.2.Editing of any Qty received / issued

4.8.3.Back Up and Restore

This is to allow the user to make a backup of the database and save it at any user given location. The same utility should allow a previously backed up database to be restored. The database/backup file needs to be stored in an encrypted or password protected format.

5.Technical Inputs to Developers

In addition to the above stated requirements, the following inputs shall be provided to developers:-

1. A working .exe file incorporating all above functions.
2. Database in MyQSL or a .sql file containing desired tables and sample data matching .exe file.
3. Code of events i.e. Click events of controls on different forms and shared code in the form of modules with common functions used throughout application.
4. Detailed briefing on functioning of application shall be given initially and thereafter from time to time as the project progresses. This will ensure accurate deliverables with least possible corrections to business logic other than run time errors.
5. Business Logic is well tested, proven and is to be as per events mentioned above.

6.System Requirements

The below mentioned requirements are to be incorporated in the design and development of the system.

1. Proposed system is to be a browser based interfacing system. Need to ensure that system works on the latest versions of Internet Explorer, Chrome and Firefox without any rendering or functional issues.
2. Proposed system is to be a multi-user system. Need to ensure that multiple users can access the system and its functionality without any data and performance issues.
3. Security is paramount. System should be developed in a way to ensure that data security is maintained. One user should not be able to view data of other users.
4. System should be safe from security vulnerabilities like SQL injection, session hijacking and information disclosure. Data should not travel in clear text between the server and the browser.
5. Highly modular design to be incorporated. Generic reusable functions are to be created to the maximum extent possible. For e.g. displaying data in a grid, printing a data grid, exporting to pdf etc. Functions should be flexible and easily updateable in future to accommodate new columns and data.
6. Access control system is required that allows different users to be assigned rights to use different features of the application. Access control management should be easy to perform for the currently developed functionality as well as for future.
7. Appropriate coding guidelines to be used. All function as well as variable names should be self-explanatory. Certain naming criteria shall be given by us.
8. Ensure system is coded according to ASP.Net MVC best practices as per below links:

1. Visual Studio Code Analysis for static code analysis should be performed and results to be shared postfixing of all issues.
2. Detailed code commenting should be done on all the code developed to ensure that future understanding and maintenance will be easy to perform.
3. Transactions should be ACID. In case of a multi-table/multi-insert transaction, if any transaction fails then the entire transaction should be rolled back.
4. Debug logs should be flag enabled and should contain detailed information to enable easy debugging whenever any error occurs.

7.Deliverables

The expected deliverables are:

1. Technical architecture document detailing the system design, component structure and interfacing.
2. Complete Source Code for all of the developed system including ASP.Net, JS, CSS and other code required for installation and execution of the same.
3. Unit test cases for ensuring that function units have been coded correctly
4. Manual containing detailed step-by-step deployment procedure along with pre-requisites to be installed on any desired system. The manual should also contain instructions to configure the database and application server for optimal performance and speed.

8.Other Terms and Conditions

The below mentioned terms and conditions are to be noted:

1. In case your quote for this proposal gets accepted then legal agreement will need to be signed. This will contain the terms related to payment and non-disclosure of artefacts shared.
2. Payment terms: 90% of the agreed amount would be paid once the final delivery of the software is made and is found to be as per the requirements outlined above and without any open functional defects. The remaining 10% amount will be kept on hold for the duration of the warranty period. Once all open defects have been fixed the remaining amount would be paid.
3. The warranty period of the code would be 3 months from final delivery, and any defects reported within the time frame should be fixed free of cost by the developers.
4. All the code and artefacts developed will be property of the CIST and under no circumstances will be reused, published, shared and disclosed though any means of transmission and publication.
5. Weekly progress reports to be shared detailing the extent of what has been accomplished for this week, any impediments faced and the plan for the subsequent week.

PAGE 1