USER REQUIREMENTS:

INVENTORY AND PROCUREMENT SYSTEM (IPS)

Prepared By: SAQIB SIKANDER SAIF-UR-REHMAN SAQIB JAVAID USMAN AFTAB

For Mr. MUKHTAR

OVERVIEW
It is responsible administrative and management work assisting the Purchasing Department Director by insuring the effective and efficient operation of Purchasing Department procurement and inventory automation systems. Work is performed with considerable independent judgment, discretion and initiative. An employee in a position allocated to this class is responsible for planning, coordinating and implementing Department/Countywide procurement and inventory automation systems. This position reports to the Purchasing Department Director. Work is evaluated based on quality and quantity of results obtained and observation of overall effectiveness.

3.1

Functional Requirements
Initiate Requisition Validate Requisition Pre-Procurement Process Procurement Purchase Goods & Services Invoice Processing/Billing Inventory Description Inventory Issuance Goods Return Sale & Disposal of Stock Reports

3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.1.9 3.1.10 3.1.11

3.4
3.4.1 3.4.2 3.4.3 3.4.4

Non-Functional Requirements
Requisition Process Procurement Inventory Disposal

3.1

Functional Requirements

3.1.1 Initiate Requisition 3.1.2 Validate Requisition 3.1.3 Pre-Procurement Process 3.1.4 Procurement 3.1.5 Purchase Goods & Services 3.1.6 Invoice Processing/Billing 3.1.7 Inventory Description 3.1.8 Inventory Issuance 3.1.9 Goods Return 3.1.10 Sale & Disposal of Stock 3.1.11 Reports

3.1.1 INITIATE REQUISITION

Functional Requirements

Objectives/Overview of Process:
1. To initiate the Requisition process in different departments of Ministry.

2. Requisitions will be project-based (Development Requisition). 3. Annual or Normal Requisition (Non-Development Requisition). 4. The process will provide a Requisition template. 5. The Requisitions will be generated by selecting items from the inventory (project / Non-Development) and submitted to SO (G), SO (Admin). 6. The Requisition (Development, Non-Development) will be prepared (in high authority section) by low authority staff like Stenographer, approval from respective personal assistant in the office will be required before submission to SO (G) and SO (Admin). 7. A procurement case will be prepared and forwarded to higher authorities by using Internal Communication module. 8. The system will provide support to save, edit and iterate Requisition to assist MIT employees.

3.1

Functional Requirements

PROCESS CYCLE ( INITIATE REQUISITION) Prepare Development Requisition

001. 002. 003. 004. 005. 006.

Select Project Add / Edit Items and Quantities Save Requisition View User Owned Requisition Edit Requisition Submit Requisition

Prepare Non-Development Requisition

001. 002. 003. 004. 005.

Add / Edit Items and Quantities Save Requisition View User Owned Requisition Edit Requisition Submit Requisition

Prepare Annual Requisition

001. 002. 003. 004. 005. 006.

Edit Items and Quantities View Annual Statistics Save Requisition View User Owned Requisition Edit Requisition Approval Cycle

3.1

Local Approval Cycle

3.1.2

VALIDATE REQUISTION

Functional Requirements

Objectives/Overview of Process:
1. The objective of this process is to validate the Requisition and to take an appropriate action for issuance of fresh Procurement. 2. The validation of Requisition will take multiple policies, logic and decision making into account before approval or rejection of Requisition. 3. Requisitions fulfilling the criteria of authorization, rules and regulation are entertained. The Requisitions will be entertained either from inventory or a new procurement process will be initiated under the rules of General Financial Rules (G.F.R). 4. The Requisitions that will contain items of different account heads will be broken to their respective account heads. 5. A procurement case will be prepared if the items are not presented in inventory. If multiple Requisitions of the same account head will be raised, a single procurement case will be prepared for all of them.

3.1

PROCESS CYCLE ( VALIDATE

REQUISITION)

Functional Requirements

Process Requisition
001. 002. 003. 004. 005.

View Requisitions List View Requisition Details Verify Requisition Decision on Requisition Generate Issuance Request

Prepare Procurement Case

001. 002. 003. 004.

Break/Merge Requisitions on account head Approximate Costing Verify from Budget Decision on Procurement

Approval
001. 002.

Approval / Rejection Approval Cycle

3.1

1.3.3

PRE-PROCUREMENT PROCESS

Functional Requirements

Objectives/Overview of Process:
References Chapter 8 of G.F.R. Sample Quotations Sample Tenders Functionality Specification document

1. Pre-Procurement process will be used for establishing the groundwork for purchasing items against procurement cases. 2. Procurement process will be triggered after the approval of method/strategy set in this process. 3. Rules and policies will be defined for procurement methods i.e. direct purchase/petty purchase, quotations and Tenders. In few exceptional cases, a No Objection Certificate (NOC) will be obtained before Tendering. 4. After the approval of Tender or quotation, subsequent process of procurement will be initiated.

3.1

PROCESS CYCLE ( PRE-PROCUREMENT

REQUISITION)

Functional Requirements

Select Policy for Purchase Order flow

001. 002. 003.

Amount based Procurement Policy setup View Approved Procurement Cases Select Procurement Method

Process Quotation
001. 002. 003. 004.

Generate RFQ (Request for Quotation) Input Received Quotation View Quotations Local Verification of Quotations

Process Tender after NOC

001. 002.

Generate Tender Iterate for Tender Approval

Process Tender
001. 002. 003.

Generate Tender Attach documents with Tender Store NOC Details

Reject Tender

3.1

001.

Reject Tender

1.3.4

Procurement

Objectives/Overview of Process:

Functional Requirements

1.

This process will be used for the selection of Supplier for the current Tender or Quotation. It consist of several subtasks like evaluation committee formation, preparation of evaluation criteria, input bids received, bidder evaluation, recording of Minutes of Meeting till a comparative analysis report will be generated for items and Suppliers. There will be no restrictions on the number of member in Technical Committee. In most cases SO (G), SO (Admin) or Project Coordinator will be the only members. Similarly in most cases only one evaluation criteria i.e. cost will be considered. Multiple Suppliers will be selected for a single procurement case. A formal contract will be prepared for the selected Supplier. The contract will not be compulsory but will be required in few cases. The contract will entail all the terms and conditions for the Supplier to agree. If the Supplier isnot be agreed on terms, next Supplier in comparative analysis will be given a chance, SO (G), SO (Admin) and Project Coordinator will have the authority to re-Tender in exceptional circumstances like this. Output of this process will be the Purchase Order for the successful Suppliers/bidders.

2.

3. 4.

5. 6. 7. 8.

3.1

9.

PROCESS CYCLE (PROCUREMENT

REQUISITION)

Functional Requirements

Formulation of Technical Committee

001. 002. 003.

Select Procurement Case Show Members list Add Member

Evaluation
001. 002. 003. 004. 005. 006.

Evaluation Criteria Input Received Bids Evaluate Bidders Minutes of Meeting Generate Comparative Analysis Report Local Verification of Evaluation

Supplier Approval Cycle

001. 002. 003. 004. 005.

View Tender/Quotation Send report to appropriate Member for approval View Request for approval Approve/Reject Contract Supplier

Generate P.O.

3.1

001.

Generate Purchase Order

1.3.5

Purchase goods and services

References Chapter 8 of G.F.R Functionality Specification document

Functional Requirements

Objectives/Overview of Process:

1. The objective of this process is to receive the goods from Supplier in a reliable and crystal clear method. 2. To support the cause a Technical Committee will be formulated that will inspect these goods. There will be no restrictions on the number of members in Technical Committee. 3. In most cases SO (G), SO (Admin) or Project Coordinator will be the only member. After inspection a certificate of valid items received will input to system. 4. After inspection a certificate of valid items received will input to system. In case of bad or partial delivery the committee will send the notification to Supplier for clarification and the bad items back. 5. The Supplier will send a new schedule for delivery. The delivery will be recorded in the system against the Purchase Order. 6. In case of successful completion of delivery a Delivery Challan will be sent to Supplier by the SO (G), SO (Admin) or Project Coordinator. 7. . If any fraud will be found or the Supplier fails to deliver the items in schedule SO (G), SO (Admin), Project Coordinator will block the Supplier temporarily or permanently by Blacklisting the Supplier.

3.1

PROCESS CYCLE (PURCHASE GOODS & SERVICES)

Functional Requirements

Basic Function

Breakdown ID
001. 002. 003. 004. 005.

Sub-Functionality
Technical Committee Goods Evaluation Criteria Issuance of certificate Notification to Supplier Update Delivery Schedule

Inspection Process

Process Received Goods

001. 002. 003

Update Stock Delivery Challan Receipt Blacklist Supplier

3.1

1.3.6

Invoice Processing / Billing

Objectives/Overviews of Process:

Functional Requirements

1.

The purpose of this module is to record and process the invoice provided by the Supplier. The invoice details (items, quantity, price, discounts) will be inputs and the scanned image of the invoice sent by Supplier will be kept in the system. SO (G), SO (Admin), Project Coordinator will prepare a case by attaching relevant documents of procurement that might be useful for Finance Section. The Invoice will be sanctioned and forwarded to Finance Department. The users will use the module to view the invoices and there status of processing. Details of invoice with consolidated documents that generate the invoice (Requisition, Quotation, Tender, Purchase Order, Delivery Challan and Invoice details) can be viewed. The module will be coupled with Finance module. Any objection / clarification on the invoice will be sent by Finance Officer. SO (G), SO (Admin), Project Coordinator will resubmit the invoice by providing clarification and attaching documents to the invoice case. The module will use Internal Communication to derive the workflows.

2.

3.

4. 5. 6.

7.

8.

3.1

9.

PROCESS CYCLE (INVOICE PROCESSING/BILLING)

Functional Requirements

Basic Function

Breakdown ID
001. 002.

Sub-Functionality

Record Invoice

Record Invoice Details Sanction and Submit Invoice

Process Invoice

001. 002. 003.

View Invoices List View Invoice Details Resubmit Invoice

3.1

1.3.7

Inventory Description

Objectives/Overview of Process:

Functional Requirements

References

Functional Specification document

1. The objective of this process is to manage the stock. This process will also maintain the Suppliers record. 2. The inventory administrator will perform operations. e.g. adding, editing and deleting items and their specifications under different account heads/category. 3. Inventory Administrator will also set an upper and lower threshold level and depreciation of each item. 4. Stock in charge keeps track of the health of items. Inspections will be made by SO (G), SO (Admin) or Project Coordinator. 5. The inspection result about the health of items will be recorded in the system. 6. The Inventory Administrator can add, delete, edit and search a Suppliers record. 7. The Inventory Administrator will also provide the information regarding the Supplier to item link. 8. Report can also be viewed against Supplier/s.

3.1

PROCESS CYCLE (INVENTORY DESCRIPTION)

Functional Requirements

Basic Function

Breakdown ID
001. 002.

Sub-Functionality
Define Items (Data Dictionary) Inventory Inspection

Manage Inventory Define Suppliers

001. 002.

Add / Edit Supplier Search Supplier

3.1

1.3.8

Inventory Issuance

Objectives/Overview of Process:

Functional Requirements

References

Sample Copies of Register maintained in MoIT

1. 2. 3.

This process will cover inventory issuance to the Requestor. Requestor will be the person who raised the Requisition or a contractor etc. SO (G) will generate the issue request and submit it to the stock in charge for issuance. Issue request will be generated from SO (G) in different cases one at the time when Requisition will be raised and stock will be available and second after the procurement of item against the Requisition and goods received; means order fulfilled. Third in case the Requestor raises Requisition for the replacement of item and item is available. Once the request is raised, it will be submitted to Stock Incharge and Stock Incharge will generate the Delivery Receipt for the request and issue goods to Request Initiator together with delivery receipt that will be signed off by the Requestor after accepting the goods. Stock Incharge will be able to view all the delivery receipts that have been issued and accepted/signed off by the Requestor for his information. The items can also be issued from Non-Development to Development department. Items can also be issued to the contractor as per the rule. The contractor has to pay the recovery rate and other charges.

4.

5.

6.

7.

3.1

8.

PROCESS CYCLE (INVENTORY ISSUANCE)

Functional Requirements

Basic Function

Breakdown ID

Sub-Functionality
View Issuance Request View Issuance Details

Receive Issuance Request Process Issuance

001. 002.

001. 002.

Issue Items Update Stock

3.1

1.3.9

Goods Return

Functional Requirements

Objectives/Overview of Process:
References Sample copies of Register maintained at MoIT

1. This process aims to maintain the stock record when goods will be returned when a request is put up for replacement. 2. The SO (G), SO (Admin), Project Coordinator will check the reason to replace the items and has authority to approve or reject the request. On approval the goods return case will be sent to Stock Incharge. The Stock Incharge will update the stock for returned items and will enter the status of returned items i.e. Serviceable or Damaged.

3.

4. If items will need to be replaced, Stock Incharge will generate a Delivery Goods Receipt and send it to the Request Initiator. 5. The Store Incharge will record the signed receipt. The Request Initiator can view the status of request during the process.

3.1

PROCESS CYCLE (GOOD RETURN)

Functional Requirements

Basic Function

Breakdown ID
001. 002. 003.

Sub-Functionality
Return Goods Request View request status Replacement approval

Goods Return Request Update Stock Deliver Items

001. 002. 003.

View Return Goods List Record Returned Items Record Damaged Items

001. 002.

Delivery goods receipt View delivery receipt

3.1

1.3.10

Sale and Disposal of Stock

Functional Requirements

Objectives/Overview of Process:
References Chapter 8 of G.F.R.

1. The purpose of this module is to record and take an appropriate action on inventory that will need to be disposed. 2. SO (G), SO (Admin) or project coordinator will develop a case for the items that will be reported to be obsolete, surplus or unserviceable. The disposal case will be prepared and sent to the Competent Officer with rights to write off a loss. 3. Competent Officer will take a decision on the method of disposing the stock i.e. by auction, sale to officer, other department, or any other decision like donation, permanently purging the stock.

4. The Competent Officer will sanction the disposal by sale or other wise. 5. The sale and disposal will be recorded and inventory will be issued against the request submitted.

3.1

PROCESS CYCLE (SALE & DISPOSAL OF STOCK)

Functional Requirements

Basic Function

Breakdown ID
001. 002. 003. 004.

Sub-Functionality
View Disposable Stock Generate Disposal request Local Verification of Disposal Case Submit Request to Competent Authority View Disposal Requests View Disposal Request Content Disposal Decision Disposal Action Sales of Surplus to Private persons of Store Sales by Auction to other departments or authority Other decision taken Inventory Issue

Prepare Disposal Case Sanction Disposal Process Disposal

001. 002. 003. 001. 002. 003. 004. 005.

3.1

Release / Issue Order

001.

1.3.11

Reports

Functional Requirements

Objectives/Overview of Process:
References Functionality Specification Document

1. In order to assist management and decision makers summarized reports can be displayed. 2. Reports will be generated for different areas of procurement and inventory management.

3. By just a few clicks a report will be selected and summarized information of area of interest e.g. Requisitions, procurements, Tenders, quotations, issuance etc. will be displayed.

3.1

PROCESS CYCLE (SALE & DISPOSAL OF STOCK)

Functional Requirements

Basic Function

Breakdown ID
001.

Sub-Functionality
View Reports

View Reports

3.1

3.4

Non-Functional Requirements
Requisition Process Procurement Process Inventory Process Disposal Process

3.4.1 3.4.2 3.4.3 3.4.4

Non-Functional Requirements

1.
1.

REQUISITION PROCESS

2.

3. 4. 5.

6. 7.

8.

Requisitions in development projects are made only against the Project inventory. The inventory contains only those items that are enlisted in PCI document. If any Requisition is raised by supporting staff for the section, it must be verified by the authorized officer of respective section. e.g. a stenographer in Secretary office raises Requisition for stationary. It must be verified by Personal Assistant to Secretary before submission to SO (G), SO (Admin). Partial Requisitions can be fulfilled. In case of partial Requisitions issuance and procurement cases are generated. Annual Requisitions are based on Stationary account head only. However the system supports addition of items from different account heads. Procurement is based on the account head defined in FPBS. Therefore, Requisitions containing items of different account heads must be separated on the basis of item account heads. Items in Requisitions that belong to common account head must be consolidated in one procurement case. SO (G), SO (Admin) must be given an interface to finance planning and budgeting system to verify the procurement. Procurement cases are forwarded to competent officers for approval according to the delegation of powers. The officer can take a decision if he/she has the power of decision on amount in account head. Approval cycle for the Procurement case can be postponed up-till the process of Tender or quotation. Complete case will be submitted together with Tender or quotation.

1.2

Non-Functional Requirements

2.
1.

PROCUREMENT PROCESS

2.

3.

4.

5.

6.

Procurement cases are procured separately depending on the approximate amounts i.e. for procurements less than Rs. 4000; a Purchase Order is generated directly. For amounts in range of Rs. 4000Rs. 40000 a quotation process is initiated. Amounts exceeding Rs. 40000 fall in Tender domain. For even higher amounts e.g. above Rs. 50000 or any amount threshold set in delegation of power an NOC must be obtained. Officers (SO (G), SO (Admin) or Project Coordinator) can change the default course of procurement described above by providing appropriate reasons to adopt the methodology. There are no restrictions on members of Technical Committee i.e. SO (G), SO (Admin), Project Coordinator. There can be single evaluation criteria i.e. Cost of procurement. Cost of procurement must be the part of evaluation criteria. Competent authority has the rights to Reject the Tender initially or after the selection of Supplier. Multiple Suppliers can be selected against procurement. In case of fraud or the Supplier is unable to deliver the goods, SO (G), SO (Admin), Project Coordinator can temporarily or permanently black list a Supplier. Invoices should be entertained with high priority and supporting documents must be attached.

1.2

Non-Functional Requirements

3.

INVENTORY PROCESS

1. Nominal issues of inventory must be recorded in the system.

2. Items are issued to request initiator after he/she signs the inventory delivery challan.

3. Goods can be issued to development project or any other department of ministry but follows the same principles of issuance and receipt.

1.2

Non-Functional Requirements

4.

DISPOSAL PROCESS

1. Inventory marked as surplus, obsolete or unserviceable can be disposed after permission of competent authority who can write off all losses.

2. If surplus goods are to be sold to internal employees the officer must provide a reason / clarification to perform this action.

1.2

THANX.