Attachment_1.a_NMS_Functional-Requirements-Document_March_2017.pdf

Functional Requirements Specification

PROPOSED NMS ERP

NMS Functional Requirements Document | Draft 3

PROPOSED NATIONAL MEDICAL

STORES

ERP

Functional Requirements

Specification

Draft 3

1.0 DOCUMENT VERSION HISTORY AND CONTROL RECORD

Version No. Date Author Amendment details

1.0 17th September 2014 CHAI & NMS Initial Draft

2.0 September 2015 NMS IT Steering

Committee

Updates to dates and process changes

3.0 March 2016 NMS IT Steering

Committee

Current Draft

TABLE OF CONTENTS

1.0 DOCUMENT VERSION HISTORY AND CONTROL RECORD

2.0 PURPOSE OF THIS DOCUMENT

2.1 OBJECTIVES OF THE FUNCTIONAL REQUIREMENTS SPECIFICATION DOCUMENT

2.2 DISTRIBUTION OF THE FUNCTIONAL REQUIREMENTS SPECIFICATION DOCUMENT

2.3 REVISION OF THE FUNCTIONAL REQUIREMENTS SPECIFICATION DOCUMENT

3.0 REFERENCE DOCUMENTS

4.0 SCOPE OF THE FUNCTIONAL REQUIREMENTS DOCUMENT

5.0 LIST OF BUSINESS PROCESSES

6.0 USER ROLES

7.0 FUNCTIONAL REQUIREMENTS

7.1 PLANNING

7.2 REQUISITION TO PAYMENT

7.3 FINANCE

7.4 WAREHOUSING & RECEIPTS

7.5 CUSTOMER ORDER RECEIPT & PROCESSING

7.6 HR & ADMINISTRATION

7.7 BUSINESS INTELLIGENCE/ MANAGEMENT & EXECUTIVE REPORTING

2.0 PURPOSE OF THIS DOCUMENT

This document specifies the functions that any proposed solution needs to support in order to meet the high level business requirements, set out in the Business Process Review (BPR).

2.1 Objectives of the Functional Requirements Specification Document

2.1.1 To define the scope of business objectives, business functions, and organizational units

2.1.2 To identify the business processes that the solution must facilitate

2.1.3 To facilitate a common understanding of what the functional requirements are for all parties involved

2.1.4 To establish a basis for defining the acceptance tests for the solution to confirm that what is delivered meets requirements

2.2 Distribution of the Functional Requirements Specification Document

2.2.1 This manual shall be distributed to the following persons, offices and / or locations from where it shall be accessed:

• The Board of Directors.

• Members of MCM.

• Internal Audit Department

• NMS Server (soft copy).

• The NMS Registry.

2.2.2 The distribution of this manual outside NMS shall be at the discretion and approval of the Accounting Officer.

2.3 Revision of the Functional Requirements Specification Document

2.3.1 The latest version of this manual once approved shall immediately replace any other previous versions of the FRSD

3.0 REFERENCE DOCUMENTS

Document Version

NMS Business Process Review 1.2

Stores and Operations Policies and Procedures Manual 2.0

Sales and Marketing Policies and Procedures Manual 2.3

Finance and Accounting Procedures Manual 2.0

Procurement and Disposal Policies and Procedures Manual 4.0

Information Technology Policies and Procedures Manual 2.0

4.0 SCOPE OF THE FUNCTIONAL REQUIREMENTS DOCUMENT

The document covers documented functional processes in the critical departmental policies and procedure manuals and operations of NMS. It specifies the processes that will potentially be considered for automation by the ERP system. Where processes cut across business functions, the requirements have been developed to cover that aspect by attempting to provide an end to end view.

5.0 LIST OF BUSINESS PROCESSES

The following business processes were analysed for the purposes of determining the functional requirements.

Process Reference

Process Name Process Owner

S&Ov1.3sec6.0 Inventory Management SCO

S&Ov1.3sec10.0 Goods Receipt SMO

S&Ov1.3sec11.0 Warehouse Movements SMO

S&Ov1.3sec13.0 Warehouse Management SMO

S&Ov1.3sec15.0 Order processing SMO

S&Ov1.3sec17.0 Dispatch and Delivery TLO

S&Ov1.3sec19.0 Sales Returns SMO

S&Ov1.3sec20.0 Manual Order Processing SMO

S&Ov1.3sec22.0 Stock Write Off SMO

S&Ov1.3sec25.0 Processing Donation Orders SMO

S&Mv2.2sec4.0 New Customer Registration & Amendment of Customers HOSAM

S&Mv2.2sec5.0 Customer Order Processing SAMO

S&Mv2.2sec6.0 Cross Docking and Direct Delivery SAMO

S&Mv2.2sec11.0 Complaints and Issue Resolution CCO

S&Mv2.2sec12.0 Clients Service Visits CCO

PDUv3.0sec2.0 Procurement Planning HOP

PDUv3.0sec9.0 Contract Management HOP

F&Av2.0sec6.0 Accounting HOFAA

F&Av2.0sec8.0 Financial Reporting HOFAA

F&Av2.0sec9.0 End of Year HOFAA

6.0 USER ROLES

This chapter describes the different user roles defined in the FRSD

User Role Role Description Reports To

HOSAO Responsible for the overall warehouse operations and all warehouse staff.

GM

HOSAM Responsible for the overall customer or client interfacing operations and all sales and marketing staff.

GM

HOFAA Responsible for the overall financial control, management, reporting and finance and accounts staff.

GM

HOP Responsible for the overall procurement planning, management, reporting and procurement and disposal staff.

GM

HHRSS Responsible for the overall human resource planning, management, reporting and support services activities and staff.

GM

CIA Responsible for the pre and post audit activities and reporting and internal audit staff.

GM/Board Committee

QAO Responsible for the overall quality management systems and quality assurance system and staff of the quality assurance section.

CS

PRO Responsible for the overall public relations activities of the corporation.

GM

RMCO Responsible for the overall risk management and compliance activities of the corporation.

CS

MISO Responsible for the overall control and management of information technology infrastructure, activities and staff of the corporation.

GM

NMS Functional Requirements Document | Draft 3 Page 10 of 93

7.0 FUNCTIONAL REQUIREMENTS

7.1 Planning

Process objective

This process is undertaken at the beginning of each financial year.

The objective of planning is to generate calendar of activities/events and to define benchmarks that are used as controls in other organizational processes.

Planning at NMS includes the following:

� Customer Procurement � Entity Procurement Plans � Delivery Schedules � Budgeting

NMS Functional Requirements Document | Draft 3 Page 11 of 93

7.1.1 Delivery Schedule

Process Objective

Delivery Schedules are prepared by the sales department.

The goal is to build a schedule of product deliveries for all zones and facilities, and use this to monitor deliveries throughout the financial year.

Process Flow Chart

T ri g g e r/

E v e n ts

In p u

O tp

B s in e s s R e q u ir e m e n t

C ro s s R e fe re n c e s in e s s I m p o rt a n c

D a ta

S e c u ty

C la s s if ic a ti o

F o rm u s

U rs e r

R ig h

E x c e p ti o n s H a n d li g

Beginning of financial year

Order Record Distribution Schedule

Sales/ Store & Operations

Mandatory (M) | High (H) | Optional (O)

Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public)

C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 12 of 93

NMS Functional Requirements Document | Draft 3 Page 13 of 93

Delivery Schedule Requirements

Requirement Ref

Description Business Rule Business Importance M-Mandatory, O- Optional

Import distribution schedules Capture Zones, Districts, Facilities Capture Delivery Routes Capture Delivery Modes: Point To Point, Hub& Spoke(3rd Party ), Direct Delivery, Cross Dock, Emergencies Delivery start date Order Deadline (Customer view) Order End Date The system shall generate alerts/flags as different deadlines are reached. (Order Dates Alerts/ Flags – GM/HOSAM) Schedule Calendar

Point To Point (p2p) Ability to Monitor, Alert/Notify on Customer Orders not received by

i) Customer Order Deadline – To [CCA] cc [CCR]

ii) Delivery Deadline – TLO, CCD, CCR

How?

Point To Point:

a) Monthly Distribution

b) 7th Working Day of month (Order

Deadline)

c) 15th Delivery Deadline

d) No Deliveries on Mon, Tue, Weekends

& public Holidays

e) Flags/ Alerts on order deadlines

(Start & End) to relevant parties

(HOSAM)

Point To Point (p2p) / Hub & Spoke

FR 1. Every 2 months FR 2. Customer Order deadline

(COD)

FR 3. Delivery Deadline

M

Monitoring of Deliveries against Delivery Schedule M

Reporting & Visualization M

NMS Functional Requirements Document | Draft 3 Page 14 of 93

7.1.2 Customer Procurement Plans

NMS Customers submit procurement plans at the beginning of every financial year.

The customer procurement plans are required to control and monitor customer consumptions against their budgets and across various products and product categories.

Customer Procurement plans are also aggregated into a National Sales Procurement Plan that advises and provides controls to EMHS Stock Procurement against the available budgets, vote functions and product categories.

Process Flow Diagram g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c ta

S e c u s s if ic a ti o rm u e r

R ig h c e p ti o n s H a n d li

Beginning of financial year

Customer Procurement Plans

Aggregated EMHS Stock Procurement Plan

Sales Staff/ Customers

4 Mandatory (M) | High (H) | Optional (O) 5 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 6 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 15 of 93

Assumptions Made

Indicative Planning figures (IPFs) to be used if customer plans are not received

Customer Procurement Plan Requirements

Requirement Ref

Description Business Rule Business Importance M- Mandatory, O- Optional

The system shall provide Capability To Capture and Import Customer Procurement Plans in various formats including xls/xslx/csv amongst others

Procurement Plan Details Facility Information Financial Year Cycle Budget Total Annual Budget Particulars Item Code Description

UOM

Price Item Categories Planned AMC

Plan must be submitted by Submission Deadline (Usually End of March)

The system shall provide Capability To Aggregate All Customer procurement plans to national Procurement plan

Capability to change facility/Customer procurement plan Facility Procurement Plan Change must take into consideration remaining budgeted amount

The system shall have capacity for Generation of Customer Procurement Plan templates

Generation of customer procurement plan templates must considerations:

i. Items Available to Facility Level

ii. Budget Available to facility

iii. Historical Ordering behaviour* & Budget

iv. Ceiling: (Budget allocation -+ Deviation)

NMS Functional Requirements Document | Draft 3 Page 16 of 93

Ability for Customer To Download Template Procurement Plans in various formats

The system shall provide Monitoring & Reporting capabilities including reporting and monitoring

� Facilities that have not submitted plans � Comparisons between Procured Vs Budgeted amounts (Should be able to also compare consolidated figures)

NMS Functional Requirements Document | Draft 3 Page 17 of 93

7.1.3 Budgeting

NMS receives budgetary allocations from the Central Government.

In addition, NMS charges various fees for amongst other activities, procurement and distribution of EMHS Stock on behalf of the government and Third Parties (Donors).

Budgeting ensures all sources of funds and donations to NMS and constraints on the usage of these funds are captured and used to monitor and control their utilization over the financial year.

g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c ta

S e c u s s if ic a ti o rm u e r

R ig h c e p ti o n s H a n d li

Government Budgetary Allocation OBT Tool, Donations (Projected)

Finance

7 Mandatory (M) | High (H) | Optional (O) 8 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 9 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 18 of 93

Budgeting Functional Requirements

Ref

Description Business Rule Business Importance M- Mandatory, O- Optional

7.1.3.1

The System shall capture GOU/Ministry Budgetary allocations from Output Budgeting Tool (OBT) Budgetary Allocations Details

I. Ability to capture Total Allocation from MOFPED [Ministry of financial planning and Economic Development]

II. Ability to capture/select Financial Year III. Ability to define vote functions

Facility Levels e.g. Level Centre Level II, Health Centre Level III, Health Centre Level IV, National Referral Hospitals and others Special Programs that include Immunization, ARVs, Laboratory among others

IV. Ability to capture allocated budget amount for each Vote Function as specified in the Output Budgeting Tool

V. Ability to set expenditure ceiling for facilities [ability to distribute Facility Level allocation to individual facilities under that category to provide ceiling value for facility budget/plan (Total level allocation divide by number of facilities under that level)]

VI. Ability to link facilities and Commodities to vote functions and funds allocated.

MTEF (Medium Term Fund constraints)- Funds are allocated to Vote Functions based on Facility Levels[HCI, HCII - Essential medicines] &Programs (immunization, lab items, ARVs)

Vote Functions funds are allocated to facilities in the Unit based on the total allocated and the number of facilities in that Unit/Category

NMS Functional Requirements Document | Draft 3 Page 19 of 93

7.1.3.2

The system shall provide capability to capture NMS source of funds/Owners/Budget Holders (Owners – GOU, Global Fund, Clinton Foundation, USAID etc) Data Captured shall include:

i. Name of Donor/Owner/Partner

ii. Description of Donor

iii. Amount Donated

iv. Financial Year

7.1.3.3

The System shall provide capability to capture Service Types provided by NMS

NMS Provides: Procurement, Storage & Distribution, Clearing Services (PSDC) services

M

7.1.3.4

The System shall provide capability to capture the Service Charges e.g. Handling Fee and any other charge.

Details:

� Donor/Owner (GOU/Global Fund/ USAID etc) � Financial Year � Service Provided (PS, PSD, PSCD etc) � % Charge � Total Amount/Value donated/provided � Actual Charge

� NMS’ budget allocation from Government is a non-Wage Vote i.e. recurrent expenditure cannot be charged to this vote.

� A service charge (PSD): 7% on high value items, 8% on low value items is charged for services provided to the government.

Wages/Field/Internal expenses serviced through this fee

� Handling fees are charged on services provided to Other partners (Global Fund/ USAID etc.)

7.1.3.5

The System shall aggregate all charges e.g. service handling fees. GOU Allocation to NMS = X

GOU Service Charge 8%(X)

Other Handling Charges(Donations) Y

Available Budget (EMHS Stock) X

NMS Operations Budget 8%X+Y

7.1.3.6

Ability to derive operations budget total from the aggregated charges.

7.1.3.7

Capture Facilities and associate them to their respective levels of care.

NMS Functional Requirements Document | Draft 3 Page 20 of 93

7.1.3.8

Ability to define operations Vote heads; Finance Department, Human Resource Department, Customer Service and any other department.

7.1.3.9

Ability to define maximum budget allocation (ceiling) for each operations Vote heads; this will be the basis of the unit (department) plan.

7.1.3.10

The system shall produce Budget estimate report

7.1.3.11

Ability to produce report showing budget distribution per Vote heads & functions. (The different levels and their amounts)

7.1.3.12

Ability to produce report showing budget caps/ceiling per facility

7.1.3.13

Ability to produce report showing budget allocation for each facility for a given vote function

7.1.3.14

Ability to export ALL reports to various formats

NMS Functional Requirements Document | Draft 3 Page 21 of 93

7.1.4 Entity Procurement Plan

Entity procurement plans capture the departmental plans for procurement for the year.

The plans are based on the department’s allocation in the budget. (This is well discussed in the finance section)

Process Flow Diagram

Entity Procurement Plan Requirements

Requirement Ref

Description Business Rule Business Importance M-Mandatory, O- Optional

7.1.4.1

The system shall allow creation of departmental procurement plans

1. Serial No

2. Product Description

M

7.1.4.2

The system shall enable consolidation/aggregation of procurement plans

7.1.4.3

The system shall have capability for automated Approvals [Workflow] Contracts Committee Approval, Management/ Board Council Approval

7.1.4.4

Export/ Import Capability for procurement plans

7.1.4.5

Procurement Controls: procurement of items not included in the procurement plan should be denied.

NMS Functional Requirements Document | Draft 3 Page 22 of 93

7.2 Requisition to Payment

This process brings procurement, warehousing/ Receipting and finance processes together to create one seamless process.

The objective is to connect all steps in the following sub-processes:

i. Procurement Request

ii. Sourcing [RFQs, Contracting/Calloffs, Micro-procurements]

iii. Warehouse Receipting, QA, Put Away

iv. Finance Payment

7.2.1 Requisitions (Without Framework Contracts)/ Contracting Process

NMS primarily contracts suppliers over a period of time (3 Years) to supply products for which they’ve been prequalified.

This process identifies the various sourcing methods and the conditions for each.

NMS uses two documents to kick start procurement sourcing:

i. Requisition (captured in Form 5 – where no framework contracts exists)

ii. Calloff (Where Framework contracts already exist)

NMS Functional Requirements Document | Draft 3 Page 23 of 93

NMS Functional Requirements Document | Draft 3 Page 24 of 93 g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Demand Requisition (Form 5)

Demand & Existing Framework Contract

Call Off

10 Mandatory (M) | High (H) | Optional (O) 11 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 12 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 25 of 93

Requisitions Requirements (Without Framework Contracts)

Requirement Ref Description Business Rule Business

Importance M- Mandatory, O- Optional

7.2.1.1

Ability To capture Requisition(Form 5) with the following details:

Procurement Reference No

i. Entity Details

ii. Procurement Type

iii. Sequence No (Generated)

iv. Financial Year

Particulars of Procurement

i. Subject of Procurement

ii. Procurement Plan Ref No (Auto-linked)

iii. Location for Delivery

iv. Date Required

v. Member/User making request

vi. Head of Department approving/confirming request

Details of the Items to be procured

i. Item Number

ii. Description of the Item

iii. Quantity of the item

iv. Unit of Measure

v. Estimated Unit Cost

vi. Market Price of the Procurement

vii. Currency Estimated Total Cost

Part II The System should provide the ability to check if a contract exists for the items being requisitioned Ability to create tendering/bidding document for items that do not have existing contracts Ability to specify different methods of procurement including

NMS Functional Requirements Document | Draft 3 Page 26 of 93 tendering, request for quotation and others Ability to Choose a method of procurement (threshold, category – trading/non trading) Ability to add Short Listed Bidders (Prequalification of Suppliers) to a bid document Ability to add a listing of Participants of procurement [People involved in Creation of bid document] Ability to add tender evaluation members to a bid document Ability to set and add Cost of bidding document

Ability to forward document to contract committee for review & approval Ability for the Tender Committee to approve or reject based on existence of issues (Returned to procurement) Ability to Communicate to shortlisted bidders by email in restricted tenders (Other communication methods should be supported) Ability to communicate to bidders through media in open tenders

Tender Documents Collection Capture details in Form 8 Ability for bidders to collect bid documents (Bid collections documentation) Ability to capture details of persons collecting bid documents or addendum

Prebid meetings Ability to capture details in Form 10 (Pre-bid meetings) Ability to capture pre-bid meetings Ability to capture clarifications of pre-bid meetings Ability to create addendum and send to bidders

Bid Closing/ Opening Bids/ Receiving Bids Ability to capture the details in Form 11 including

i. Name and Address of supplier

ii. Date of receipt

iii. Time of receipt

iv. Number of envelops received

v. Method of receipt (whether person or bid box)

NMS Functional Requirements Document | Draft 3 Page 27 of 93

vi. Name of officer

Bid Evaluation Ability to specify documents required in the tender evaluation process Ability to check against documents availability in the evaluation process Ability to capture evaluation report.

Ability to send evaluation report to the contracts committee [ Workflow]

Award By Contracts Committee Ability for the contracts committee to approve/reject an award Ability to produce/capture Minutes of contract committee

Notice To Best Evaluated Bidder Ability to define award notice display period as specified by law Ability to allow for display of best evaluated bidder for the number of days defined above on the following:

i. Entity noticeboard

ii. PPDA

iii. NMS website

Ability to send award information to all bidders Ability to define a limit value of bid to send to the solicitor general [Workflow] Ability to alert/notify procurement to send award documentation to solicitor general based on the value specified above Ability to generate notification of award {Email Winning Bidder} Ability to issue notification award {Email Winning Bidder} Ability to stop the bid process if the solicitor general rejects the process Ability to capture Solicitor General’s Decision regarding contract award.

Ability to receive acceptance letter and invoice for framework contracts Ability to receive acceptance letter, proforma invoice and bid security

NMS Functional Requirements Document | Draft 3 Page 28 of 93

Call-offs Requirements (With Framework Contracts) for one time/ lump sum contracts

Contract Signing

Ability to capture Contract Manager Appointed by Accounting Officer and selected by user department Ability to capture Contract Implementation Plan (Form) filled by Contract Manager

Contract Monitoring Ability for procurement to monitor contract implementation Ability to capture expiry of contracts Ability to capture delivery schedules on the contract

NMS Functional Requirements Document | Draft 3 Page 29 of 93 g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Stock Position Report (AMC & Reorder levels)

Calloff process is currently managed in the Contract Management Tool – CMT (The process can be adopted from the tool)

Call off Memo

Stock Controller

13 Mandatory (M) | High (H) | Optional (O) 14 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 15 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 30 of 93

Ref

Description Business Rule Business Importance M-Mandatory, O- Optional

7.2.1.2

The shall support Generation of Call off orders The system shall enable Call off orders to be generated based on:

1) A supplier

2) Products/ Items

Call-off order converted into PO (We’ll Combine this)

7.2.1.3

The system shall capture Call-off Details including:

� Call-off Order reference no’s (generated) � Contract Number � Particulars: Quantity, unit price, UOM, Total Price � Delivery dates

7.2.1.4

The system shall validate Call-offs based on validity of Contracts Ensure contract is active (check contract period & contract status)

7.2.1.5

The system shall validate Call-off based on availability of funds Ensure there’s funds availability before approval of call-off (Specifics) – Procurement Plan Figures

7.2.1.6

The system shall enable reallocation of funds between products and product Categories

This must consider the constraints placed by

MTEF.

Algorithm for reallocation:

7.2.1.7

Monitor stock, stock expiry and call-offs and alert as stock exceeds or goes below predefined limits to enable cancelling or waiting call-offs

Call-off triggers

- Stock runs out fast

- Normal stock

- Limited/slow movement

- Extra Stock

- Expiry of stock

- Space Constraints

To be discussed in Warehousing/ Inventory

NMS Functional Requirements Document | Draft 3 Page 31 of 93

7.2.2 Prequalification of Suppliers

Prequalification of suppliers is an important sub process in the procurement process.

This process ensures that NMS gets the most value for its resources by sources from reliable, capable and cost effective suppliers.

This process ensures that the supplier on-boarding process is transparent, well documented and meets all legal requirements.

NMS Functional Requirements Document | Draft 3 Page 32 of 93 g g e r/

E v e tp s in e s s R e q u ir e m e n t C ro

R fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Gazetted Invitation for supplier prequalification

Form 6 – Request For Prequalification

Prequalification Report/ Prequalified Suppliers List

Prequalification of Suppliers Requirements

Ref

Description Business Rule Business Importance M-

16 Mandatory (M) | High (H) | Optional (O) 17 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 18 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 33 of 93

7.2.2.1

Form 8 – Prequalification Bids (List of suppliers who requested for and were issued with the prequalification document)

7.2.2.2

The System shall provide capability to capture supplier prequalification approval form. (Form 6)

Details in Form 6 must include:

Procurement Reference

� Code of Procuring & Disposing Entity � Type of Service (Works/Supplies/Non-consultancy services) � Financial year � Sequence Number (System Generated)

Particulars of Prequalification � Subject of pre-qualification � Procurement Plan Reference (Is this a reference to a line item in procurement plan?)

� Submission by PDU & Decisions of contract committee and necessary justifications (see form 6) � Declarations by PDU & Contracts committee

Date of submission to contracts committee

Prequalification Constraints Classes A – High Value High Volume B – LowValue, Low Volume

Prequalification Period expiry 3yrs

7.2.2.3

The system shall provide a configurable, graphical workflow process to enable approvals/authorizations required for this process.

7.2.2.4

The system shall provide capability to export the details of form 6 using NMS specified template

7.2.2.5

The System shall provide capability to generate a Prequalification Assessment (Form 7) from the aggregated/collated details of submitted prequalification requests.

Details of the Prequalification Evaluation (Form 7) shall include:

Procurement Reference details(Copied from Form 6)

� Code of Procuring & Disposing Entity � Type of Service (Works/Supplies/Non-consultancy services) � Financial year � Sequence Number (System Generated)

Introduction � Subject of pre-qualification (Copied from form6) � Procurement Method (Copied from form6)[ for single

All submitted prequalification requests (Form 6) are assessed in a single assessment document(Form 7), therefore, the system requires the capability to collate information from form 6 into form 7

NMS Functional Requirements Document | Draft 3 Page 34 of 93 requirements]

Invitation Details

� Prequalification approval date � Prequalification Advertisement date � List of bidders who requested & were issued with prequalification document (Attach Form 8)

Bid Closing Details

� Date Closed � Time closed � Location closed

Prequalification Submissions recorded in Form 11 (Attachment)

Bid Opening

� Date Closed � Time closed � Location closed � Attached Form 12 (Bid Opening & Attendance)

Evaluation Committee details � Date Evaluation committee approved by contracts committee � Name & Designation of each member

Details of Evaluation (as provided in Form 7) Disagreement by Evaluation committee Attachments:

� Copy of the pre-qualification document.

� Copy of the pre-qualification notice.

� Copy of all pre-qualification submissions.

Prequalification Evaluation Summary

7.2.2.6

The system shall generate a Prequalification Assessment report in PDF/MS Word format. (XLS Supplier Listing)

A template format for this report shall be provided by NMS

NMS Functional Requirements Document | Draft 3 Page 35 of 93

7.2.3 Contract Management & Monitoring

NMS contracts different suppliers to supply various commodities (Trading and Non Trading items). Monitoring supplier performance is a key to ensure NMS supplies are available when needed, and to pick out trouble cases. This process aims to ensure continuous and regular supplier reviews are performed and captured.

NMS Functional Requirements Document | Draft 3 Page 36 of 93 g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Contract Award Contract, Performance Information

Supplier Performance Report

Contract Managers/

Procurement

Contract Management & Monitoring Requirements

Ref

Description Business Rule Business Importance M-Mandatory, O-

Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public)

NMS Functional Requirements Document | Draft 3 Page 37 of 93

7.2.3.1

The System shall provide capability to capture supplier contract information and Performance indicators

(Details in the Contract Implementation Plan)

Performance indicators will include:

Timelines in delivery (from calloff dates & Delivery dates), order fulfillment capability, (additional variables to be added here)

M

7.2.3.2

The system shall have capability to export contract performance information in a format specified by NMS

7.2.3.3

The system shall provide integration to Procurement Performance Measurement System (PPMS)

7.2.3.4

The System shall provide basic performance reporting based on the performance indicators specified

7.2.3.5

The System shall provide capability for integration with a BI tool

NMS Functional Requirements Document | Draft 3 Page 38 of 93

7.2.4 Disposals

Disposals of Assets are initiated by user departments or annual asset valuations carried out by NMS.

The goal of this process is to ensure Asset disposals are within the legal procurement & disposals framework.

Process Flow to be added g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Annual valuation of assets/ Administration Department

Disposal Items Memo

Disposal of Items

22 Mandatory (M) | High (H) | Optional (O) 23 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 24 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 39 of 93

Disposal Requirements

Ref

Description Business Rule Business Importance M-Mandatory, O- Optional

7.2.4.1

The system shall allow creation of a list of items to dispose [template form to be proposed]

7.2.4.2

The system shall capture details of the valuation report

7.2.4.3

Based on the valuation, the system shall procurement will propose a disposal method.

If the value is zero, the items are to be destroyed; else, an invitation for bid is raised and sent out

7.2.4.4

The system shall provide capability to support different disposal methods:

� Public Bidding � Public Auction � Donations � Sell To Public Officers � Destruction

7.2.4.5

NMS Functional Requirements Document | Draft 3 Page 40 of 93

7.2.5 Payment Process

This g g e r/

E v e tp s in e s s R e q u ir e m e n t C ro fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Items Received Into Warehouse/ Supplier Invoice

Payment Requirements

Ref

Description Business Rule Business Importance

Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public)

NMS Functional Requirements Document | Draft 3 Page 41 of 93

7.2.5.1

The system shall have the capacity to capture goods receipt documentation. (Refer To process 8.4 )

M

7.2.5.2

System shall manage the costing for valuation purpose

7.2.5.3

System shall manage the creation of the purchase invoice

7.2.5.4

The system shall support approvals of all payment documentation

NMS Functional Requirements Document | Draft 3 Page 42 of 93

7.3 Finance

7.3.1 Finance Processes

Finance is a key support department in any organization.

The objectives of this process include:

i. To ensure adherence to the law in organizational processes.

ii. To support Financial Reporting as required by law.

iii. To support budgetary controls across the organization.

NMS Functional Requirements Document | Draft 3 Page 43 of 93

Vote Functions Summary

The image below illustrates the breakdown of government budget allocation across several vote functions and facility levels.

This breakdown sets the budgetary limits for facility levels and the controls on consumption.

NMS Functional Requirements Document | Draft 3 Page 44 of 93

Facility Funds Distribution

The diagram below shows distribution of funds across facilities per vote function.

It also illustrates aggregation of vote functions into a program. This is meant to ease order encoding and funds movement between vote functions.

NMS Functional Requirements Document | Draft 3 Page 45 of 93 g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public)

NMS Functional Requirements Document | Draft 3 Page 46 of 93

Description Business Rule Business Importance M-

NMS Functional Requirements Document | Draft 3 Page 47 of 93

7.3.1.1

Accounting Setup Ability to setup accounts using the chart of accounts (COA) Ability to setup pricelists with different versions Ability to add pricelist to a budget holder (source of fund) to allow for zero value invoices for the third party (budget holders)

Ability to setup tax categories Ability to setup tax and rates for each tax type Ability to define accounting for each tax type

Ability to setup accounting calendar Ability to define non-business days

Ability to define bank and bank accounts Ability to define default currency Ability to define new currency Ability to define an account for currency Ability to define currency conversion types Ability to define currency conversion rates

The system shall support Encumbrance accounting i.e.:

� Reserve (requisition, form 5) � Commit(LPO/Call-off � Actualize (Invoice)

7.3.1.2

Accounts Payables

Ability to define cost centers e.g. departments Ability to use accrual based accounting Ability to define banks and their accounts Ability to use multiple currencies Ability to define a base currency Ability to perform currency conversion

Ability to capture GOODS RECEIVED NOTE - GRNs (Goods Receipt Note) Ability to capture supplier/purchase invoice Ability to capture create call off order (replaces the LPO) Ability to create credit memo Ability to create a Payment document Ability to captured different payment methods including; cheque, EFT, cash

Accounts Payable Constrained to vote functions Constrained to vote heads

NMS Functional Requirements Document | Draft 3 Page 48 of 93

Government Funding Ability to manage government funding in the system as Deferred Income Ability to reduce liability as customer orders are served from the government fund already entered in the system

NMS Functional Requirements Document | Draft 3 Page 49 of 93

7.3.1.3

Integration with IFMIS/ Banks (efts) Ability to automatically make payments through EFTs Ability to integrate with IFMIS (Integrated Financial Management System)

7.3.1.4

Accounts Receivables The system shall provide support for accounting for Third party handling fees billing to.

Ability to generate customer statements reflecting actual quantities and values of supplies of donor program stock delivered.

Ability to generate customer statements reflecting actual quantities and values of supplies of government program stock delivered.

7.3.1.5

Fixed Asset Depreciation The System shall have an asset depreciation module.

The System shall have support to the following depreciation methods.

[Straight Line, Reducing Balance ….] The System shall have the ability to link depreciation methods with Asset classes [furniture and fittings, Machinery & Equipment etc].

The System shall capture depreciation start date.

The System shall generate a depreciation schedule.

The System shall accommodate revaluation of assets, done periodically (every 3 years).

The System shall provide capability to produce a depreciation report, per asset, asset class, or for all assets over a specified period of time.

The System shall provide capability to post depreciation expense to relevant accounts.

Additional basic requirements such as reporting to be added

Policy Guides Amortization of assets

7.3.1.6

Cash Management Ability to create bank accounts Ability to perform bank reconciliation Ability to automatically upload bank statements into the system

Imprest Management Petty Cash Ability to create petty cash Ability to set petty cash replenishment levels Ability to requisition for petty cash Ability to pay against a petty cash Ability to maintain petty cash levels

NMS Functional Requirements Document | Draft 3 Page 50 of 93

Per Diem Ability to define Per Diem Rates for employee job groups or classes Ability to requisition for per diem Ability to Pay against a per diem requisition

Surrendarable Imprest

Ability to make Imprest requisition Ability to pay against Imprest requisition Ability to surrender Imprest Ability to refund under-expenditure of Imprest during receipt Ability to claim over-expenditure of Imprest Ability to receive payment against an Imprest during surrender

NMS Functional Requirements Document | Draft 3 Page 51 of 93

7.3.1.7

Donor Funding/Consignments accounting

Ability to specify budget holder (source of fund) for each product while making customer order entries Ability to specify if a budget holder(source of fund) provides items for free (allowing related invoices not charge recipient facility(s)’ allocated budgets) Ability to capture invoices with actual value (for Products/Items whose budget holder/source of fund is specified as free, but should not charge the facility allocated budget.)

Ability to reflect the actual value of this donor/partner stock in the accounts.

Ability to generate customer statements reflecting actual quantities and values of supplies of donor program stock delivered.

Budget Holders: NMS, Third parties [Source of Funding for products].

Ability to indicate if items are sold/free Third party accrual account

Product Item Definition

Additional Information to Items � Budget Holders (Source of funds) � Level of Care information (Determine what facilities can order the product)

7.3.1.8

Product setup requirements Ability to specify default budget holder (Source of Fund) for a product Ability to specify default budget holder (Source of Fund) for a product category Ability to add budget holders(sources of funds) to a product during setup Ability to add budget holders(source of funds) list to a product category

7.3.1.9

Reports Ability to generate and print a Trial Balance Ability to generate the income statement (Profit and Loss Statement) Ability to generate the cash flow statement Ability to generate and print a balance sheet Ability to generate statement of retained earnings Ability to generate debtors analysis report Ability to generate creditors analysis report

Ability to generate unpaid invoices report Ability to generate payments by suppliers report Ability to generate invoices by suppliers report Ability to generate postings summary report by account Ability to generate postings summary report by date

Profit & Loss Acc Cash flow statements

7.3.1.10

The System shall provide a drill down capability from accounts total values to subaccounts and source documents

NMS Functional Requirements Document | Draft 3 Page 52 of 93

7.3.1.11

The system shall provide graphical/ easy to use workflow for approvals of accounting documents (Imprest/Invoices/ Payments etc).

7.3.2 Asset Management

Asset management is an important process in finance. The objectives of this process include:

i. Creation of an asset registry.

ii. Asset Maintenance

iii. Asset allocation management g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public)

NMS Functional Requirements Document | Draft 3 Page 53 of 93

Description Business Rule Business Importance

NMS Functional Requirements Document | Draft 3 Page 54 of 93

7.3.2.1

Ability to capture Asset Receipt Note Ability to capture Supplier invoice with items of type Asset Ability to capture GOODS RECEIVED NOTE - GRN with items of type Asset Ability to register Asset acquisition cost Ability to register an Asset into the System Ability to register asset categories Ability to define/specify parts of an asset

Asset Maintenance

Ability to register asset meter types (hours, days, mileage etc) Ability to generate a maintenance schedule for assets Ability to generate a work order/ a job card based on maintenance schedule Ability to generate a work order based on an asset breakdown (Preventative/) Ability to process work orders/ job cards through workflow Ability to notify on items approaching maintenance based on the schedule

Asset Location Management

Ability to capture locations for assets Ability to assign location to assets Ability to assign/allocate an asset to a user Ability to re-allocate an asset to/from a user Ability to move an asset from one location to another Ability to give a report of assets and their locations Ability to import assets and their locations into the system

7.3.3 Partner Relations

NMS Functional Requirements Document | Draft 3 Page 55 of 93

This process/module deals with partner relationships management.

Key Objectives include:

i. Partner Records and Contacts management [Basic CRM functionality]

ii. Issues & Complaints Management

iii. SLA Monitoring g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Partner Relations Requirements

Requirement Description Business Rule Business Importance

34 Mandatory (M) | High (H) | Optional (O) 35 Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public) 36 C=Create; R=Read; U=Update; D=Delete

NMS Functional Requirements Document | Draft 3 Page 56 of 93

Ref M-Mandatory, O-

7.3.3.1

Customer Relationship Management The system shall have the capability to maintain customer records.

The data to be captured include:

Customer basic data : Names, Code, Address, Contacts, budget allocation

Basic CRM functionality

Targeted to Customer Care Representatives

7.3.3.2

The system shall provide an Issues & complaints Management module.

The system shall also automate the issues and complaints workflow.

The system shall also allow for carrying out of simple surveys.

7.3.3.3

The system shall provide Events & Calendar Tracking

7.3.3.4

The system shall provide capability to record Notes, Meetings and Tasks Logging

7.3.3.5

The system shall provide capacity for Logging of Calls/ Management of customer calls by CCRs

Records customer visits by CCRs Recording of actual calls (Call centre capability)

7.3.3.6

The system shall provide capability SLA agreement monitoring

7.3.3.7

The system shall support Compliance Management [specifics required]

- Stakeholder requirements [e.g.

Submissions to stakeholders, scheduling & calendaring of submissions, alerts for non-submission]

NMS Functional Requirements Document | Draft 3 Page 57 of 93

7.4 Warehousing & Receipts

This process aims to streamline the warehousing processes for higher efficiency and productivity.

7.4.1 Warehouse Receipt Process

This process captures the steps followed in receipt of items from a supplier.

The aim is to streamline receipts process by removing redundant steps from the process.

NMS Functional Requirements Document | Draft 3 Page 58 of 93 g g e r/

E v e tp s in e s s R e q u ir e m e n t

C ro s s R e fe re n s in e s s I m p o rt a n c e ta

S e c u s s if ic a ti o n rm u e r

R ig h ts c e p ti o n s H a n d li

Supplier Delivery Notification

DELIVERY NOTE/

GOODS

RECEIVED NOTE

- GRN, Invoice, NDA Clearance, Letters of undertaking

Stock Available, Supplier Payment

Warehouse, QA, Audit, Finance

Description Business Rule Business Importance

Level 1 (Highly Confidential) | Level 2 (Confidential) | Level 3 (Internal Use) | Level 4 (Public)

NMS Functional Requirements Document | Draft 3 Page 59 of 93

7.4.1.1

The system shall provide for as much and flexible information capture at goods receipt (to be able provide for the varying requirements of various partners/donors/owners of stock) The system shall capture supplier delivery notification through NMS Portal/ or Email

7.4.1.2

The system shall support generation of delivery bookings for suppliers.

Suppliers inform NMS in advance on delivery & a booking is issued by NMS

7.4.1.3

The System will link delivery bookings to purchase documentation i.e: Calloff/ LPOs, Supplier Contract

7.4.1.4

The System shall capture scanned supplier documentation on goods delivery.

Suppliers Present – NDA Release/ DELIVERY NOTE/ Invoice/ Letter of Undertaking(Short shelf life items)

7.4.1.5

The System shall capture Goods Verification data. Goods types, Quantity (Control) – flexibility, but max quantity delivered = quantity ordered Batch Nos/Expiry Manufacturer Country of Origin

7.4.1.6

The system shall support capture of Quality Assurance review. Product specification documentation (text field capture) Documentation Review Physical inspection of items

7.4.1.7

The system shall support goods receipt process Audit Full Process Review – to ensure all steps are received

7.4.1.8

The system shall provide capability to quarantine Stock Stock Put-away done before QA

7.4.1.9

The system shall support bar coding technology in goods receipt and put-away. The system shall tag products (tag product code to bar code) and palettes at goods receipt.

Note this means an item delivered by different suppliers may have different barcodes , so there’s need to be able to link a single product with multiple barcodes.

7.4.1.10

The system shall provide capability link Items to the palette on which they sit.

Capture Palette Locations, Warehouse Zones, Map of the Warehouse Capability to report free storage locations, Free Palette locations, Cold storage areas

NMS Functional Requirements Document | Draft 3 Page 60 of 93 that are free (in cubic meters)

NMS Functional Requirements Document | Draft 3 Page 61 of 93

7.4.1.11

The system shall support cycle counts. This should be seamlessly embedded on the RF Guns.

Support Spot checks, 7.4.1.12

The System shall support intelligent cyclic/ round robin/ random assignment of cycle counts tasks to pickers

Linked to order picking (nth/ random picker prompted to recount stock) (Bulk storage areas not an issue) – Margins of error allowed, cyclic/ round robin assignment of picker to count

7.4.1.13

The system shall support intelligent warehouse zoning Warehousing zoning: Picking areas, bulk picking areas, Count Zones, 7.4.1.14

Support intelligent Pick faces based on � Frequency of picks � Volume � Weight � Item value

Organization of the warehouse should be based on given parameters.

7.4.1.15

The system shall support flexible item picks based on:

� Batch Nos � Manufacturer � Country of origin � Location [zone] � Warehouse

7.4.1.16

The system shall support intelligent put-away to bulk storage based on variables including:

� Frequency of picks � Volume � Weight � Item value � Nature of Item [Fragile etc] � Handling type[Cold chain items]

Graphical Visualization of Warehouse Layout

7.4.1.17

The system shall support physical access controls based on assigned duties. Integration to access control systems is required.

7.4.1.18

The system shall provide BI dashboards for cycle counts variation analysis

NMS Functional Requirements Document | Draft 3 Page 62 of 93

7.4.1.19

The system shall support Intelligent alerts and notifications for stock write-offs based on consumption rate, demand, AMC etc

Write-offs shall be based on similar principles as selling stock (FEFO/ FIFO)

Reports shared for action Actions

- Write Off

- Donation(Recorded as an Expense to

NMS)

Purchase Return

7.4.1.20

The system shall support Financial reconciliation of written off stock

7.4.1.21

The system shall support configurable Product expiry Prompts, alerts & notifications

7.4.1.22

The system shall support Reverse logistics – Purchase Returns � System shall capture Returns outwards (Returns Out Form) � The system shall support capture of Credit Notes (from supplier)

The system shall support Returns outwards Approvals

Causes of Purchase Returns:

� Wrong spec � Over-delivery � Quality � Wrong spec (e.g. shelf life)

Follows normal order processing (using Return Order form), Financial Reconciliation (Invoice, Credit Note, D-Note)

7.4.1.23

The System shall support Returns Inwards – Customer Returns The Systems shall support capturing Customer Returns based on customer Discrepancies form input

The System shall provide customer returns form on the NMS portal for customer self service.

The System shall link returns inwards to complaints mgt/ ticketing workflow

The system shall support reintroduction of returns into stock

The system shall support Financial Reconciliation of returned items.

Customer Credited with value of returned stock, and inventory value debited with corresponding returned value.

Caused by:

Overissue Shelf life

The system shall Check stock viability/ Quality

Returned items financial reconciliation will be based on sale price.

NMS Functional Requirements Document | Draft 3 Page 63 of 93

7.4.1.24

The system shall link returned items to customer sales order

7.4.1.25

The system shall support bar coding of delivery documentation

7.4.1.26

The system shall support item costing and Supplier Payment on receipt of items. (Finance)

Happens after QA & Audit Purchase Value = Invoice Value + Any Other Charges [Several payments Made under one supplier invoice?]

7.4.1.27

The system shall support intelligent stock movements (Replenishment waves)…