The file's text, extracted by GovTribe without its formatting.
FUNCTIONAL REQUIREMENTS SPECIFICATIONS CHECKLIST
This section of Functional Requirements takes care of the General system requirements
Please indicate your response as one of the following for each specification.
Sup - Functionality available as a standard package feature including Supporting the requirements via modifications (screen configurations, reports, GUI tailoring, etc.)
3rd- Supported via a third party solution
Cus - Functionality not available. It would be customized to meet the requirements i.e. changes to source code
Ns- Functionality not supported
Instructions
Complete the table by placing an X in the appropriate column for each criterion. The X’s should represent the current state of a particular product or service. There is no correct number of X’s that the review team is looking for. However, customizations and 3rd party tools should represent no more than 20% of the required functionality.
Response Value Table
| Component |
| Required solution component/s (with version where necessary) |
| Comment |
| Indicate the section and page number in your proposal where you are complying to the given criteria |
| No |
| Requirements |
| Sup |
| Cus |
| 3rd |
| Ns |
| Component |
| Comment |
The proposed system should
| 1. |
| be based on multi-tiered architectures |
| 2. |
| support porting of data from legacy systems |
| 3. |
| support multiple currency |
| 4. |
| support solution architecture that shall be platform and vendor |
independent
| 5. |
| allow infrastructure simplicity and standardization |
| 6. |
| capable of supporting disaster recovery |
| 7. |
| support standard interfaces such as adapters, APIs to interface with |
standard application and legacy applications and support user exits
| 8. |
| have the ability to scale up as and when the new business applications and services are added without compromising the performance of the overall solution |
| 9. |
| support SSL and digital certificates, biometric, OTP etc. for authentication |
| 10. |
| interoperable in nature and design and development should be based on Service Oriented Architecture (SOA) supporting web services |
| 11. |
| be modular and support addition / removal of one or more modules as and when required |
| 12. |
| have a provision to input all data on-line |
| 13. |
| have a provision to accept data in batch and validate it through inbuilt |
routines
| 14. |
| have provision for reference files to be used by all validation programs(e.g. a single master Inventory file for validation of Item numbers and associated transactions) |
| 15. |
| support real-time data updates and interfaces with software from |
other vendors
| 16. |
| support e-mail integration/interface |
| 17. |
| support interfacing with PDA, Smart Card readers, RF devices, data |
acquisition system, biometric devices etc.
| 18. |
| allow up to 3 decimal places for input, calculation and reporting |
| 19. |
| have a provision to display error messages that adequately describe |
the cause of the error and the recommended course of action
| 20. |
| ensure validation of the master file values ( e.g. supplier code, item |
number) in all types of data entry
| 21. |
| support for the upgrades without affecting the current version |
| 22. |
| support for data conversion tools |
| 23. |
| Support imaging and archiving |
| 24. |
| support sharing of same master files across all modules |
| 25. |
| provide transaction level security based on the users authorized |
access profile
| 26. |
| have the database system that contain both transaction and period |
balance data of all the modules so that the report writer and inquiries can accumulate balances quickly rather than add up all the relevant transactions
| 27. |
| have screen formats within each module that are consistent in the |
way they ask for and present information
| 28. |
| allow users to customize menus and screens without requiring |
programming changes
| 29. |
| provide work flows for the transactions |
| 30. |
| provide control mechanism to check if all data processing is |
happening correctly
| 31. |
| provide a user friendly graphical user interface (GUI) |
| 32. |
| Provide user friendly and simple navigation screens. |
| 33. |
| provide the facility to capture the pictures/drawings of the items/ |
properties etc.
| 34. |
| have provision for generating reminders for time critical activities |
(as per user definitions)
| 35. |
| have provision for office automation system for: - File movement, File Tracking, Access restrictions to file sections based on role |
| 36. |
| have provision to define multiple workflows for office automation |
system based on different department needs
| 37. |
| enable role based access at: Module Level, Screen Level, Field Level |
| 38. |
| enable segregation of duties based on role based access |
| 39. |
| enable automated posting of transactions to financial accounts |
| 40. |
| have Single-sign-on facility to logon to the system |
| 41. |
| be accessible on web browser |
| 42. |
| The system should be accessible both through WAN and internet. |
The system should provide a provision for centralized updates.
| 43. |
| The system should provide the ability to maintain separate development, testing & production environments. |
| 44. |
| System should maintain the log of all the transactions for audit |
purpose
| 45. |
| Support workflow management system. The workflows should be mapped with the email id’s for sending out automated alerts and notifications |
| 46. |
| The system should contain date/time stamp and user information reflecting an audit trail on every data element. |
| 47. |
| The system should provide the ability to backup, recover, restart, and cancel jobs. |
| 48. |
| have the ability to provide mailing labels and also send out both automate emails ( like salary slip generated) and manual emails |
| 49. |
| System should maintain the log of all the transactions for audit |
purpose
| 50. |
| Allow import and export of data. It should support all commonly used formats like. .doc, .docs, xls etc. |
| 51. |
| The system's access requirements through firewalls must be clearly identified and follow standard port designations. |
| 52. |
| The system's database management system should be ODBC and/or |
OLE DB compliant.
| 53. |
| The proposed solution should offer a full suite of utility tools |
required to execute various system maintenance functions including: Backup management, Multiple monitoring sessions, Storage archival and retrieval, Performance monitoring (application and system), Ability to monitor executing jobs, Database optimization
| 54. |
| The system should allow for the assignment of or automatic document numbering. |
| 55. |
| The system should track system uptime and transaction response times in order to demonstrate operation within acceptable levels. |
| 56. |
| The system should provide automated transaction back-out/roll-back should the system fail during transaction processing and/or a transaction fails to reach normal processing completion. |
| 57. |
| System help should contain a complete data dictionary for all system tables and data fields’ terminology. |
| 58. |
| The system's comprehensive technical systems documentation designed for IT personnel should be available for the system. |
| 59. |
| System help should contain a complete data dictionary for all system tables and data fields’ terminology. |
| 60. |
| The system should allow the setup of error messages so they can be defined to allow override or block/no-override ability. |
| 61. |
| The system should indicate "Mandatory" fields in each screen to facilitate data entry |
| 62. |
| The system should support standard Internet security including, but not limited to Secure Hypertext Transfer Protocol (HTTPS). |
| 63. |
| The system should provide for integration with other software’s |
/tools and tools to easily export data
| 64. |
| The system should provide user-defined executive dashboard |
(Financial information, key performance indicators, etc.) based on user profile
| 65. |
| The system should provide users for customizations and integration |
Software Development Kit (SDK) that allows the technical staff to enhance and integrate the system.
| 66. |
| The system should support latest versions of multiple leading |
browsers like Edge, Firefox, Chrome etc.
| 67. |
| The system should provide the ability to interface or integrate with LDAP and support a single user sign on. |
| 68. |
| The system should support data-transfer via flat files (i.e.: ASCII, variable and/or fixed length, comma-delimited, etc.) |
| 69. |
| The system should have the ability to interface or integrate with the existing messaging solutions. |
| 70. |
| The system should provide enterprise application integration (EAI) functionalities. |
| 71. |
| The system should provide the ability to AutoFill on any field, i.e. auto completion of one field based on prior data entry |
| 72. |
| The system should allow transactions to be selected by any combination of date range, transaction type, User ID, etc. |
| 73. |
| The system should have a built in calendar allowing in processing and |
transaction dates for holidays, weekends, etc.
| 74. |
| The system should allow the online creation of new user-defined data fields for miscellaneous data tracking, alteration of database structure, and update of a global data dictionary |
| 75. |
| The system should provide the capability to store, retrieve, display and print imaged documents. The solution must provide the capability to receive scanned documents from document scanners having industry-standard connection protocols (SCI, TCP/IP, etc.) |
| 76. |
| The system should provide migration paths for new fields during software upgrades |
| 77. |
| The system should be scalable to accommodate potential increase in the number of users. |
| 78. |
| System error messages should appear in a consistent format across all system modules and should be customizable. |
| 79. |
| The system should have the ability to suspend after "x" attempts to access the system with an incorrect password if authentication is internal to the system. |
| 80. |
| The system should have the ability to report attempts by unauthorized users to use the system. |
| 81. |
| The system should provide the ability for users to change their own password. |
| 82. |
| The system should provide the ability to electronically interface with other applications and systems |
| 83. |
| The system should support server "virtualization" |
| 84. |
| The system should provide the use of electronic approvals in order to capture required digital signatures for electronic documents. |
| 85. |
| The system should synchronize LDAP users to facilitate a single sign on. |
| 86. |
| The system should synchronize LDAP groups to facilitate security controls. |
| 87. |
| The system should support data encryption. |
| 88. |
| The system should have the ability to define user access based on: Departments/Organizations, Roles, Individuals, Application, File or document type, User ID and administratively-defined groups, Menu, Module, Report, Transaction type |
| 89. |
| The system should have the ability to define user access based on: Database, Tables, Documents, Data elements |
| 90. |
| The system should have the ability to define and lookup a user based |
on: User Name, Role, User ID, Date user was created, Last login
| 91. |
| The system should allow users to review security transaction history in a report. |
| 92. |
| The system should allow multiple security roles to be assigned to the same user |
| 93. |
| The system should provide the ability to define security profiles to authorize users to view, update and approve data. |
| 94. |
| The system should provide for a secure database environment |
available only to defined processes
| 95. |
| The system should provide the ability to configure User ID/password rules such as length, alpha/numeric, upper/lower case, password definition and expiration period. |
| 96. |
| The system should provide ability to view or obtain security reports showing: Security breaches or attempts, Changes to security profiles, |
| 97. |
| Audit trails for all transactions which alter data anywhere in the application (add, update, delete) |
| 98. |
| Audit trail to contain- Date stamps, login user ID, context of |
transaction, fields affected and before and after data values (please specify the contents of Audit Trail record)
| 99. |
| System to support the Interfaces/Integration with other applications |
| 100. |
| Should support verification of data integrity before the data is loaded into the package tables. |
| 101. |
| System to support in-built Document Viewer to view various |
document formats such as TIFF, PDF, JPG, PDF a, MS Office documents, emails, faxes etc.
| 102. |
| Peripherals Integration with devices like bar code, printers mobile devices, etc. |
| 103. |
| Should support XML based messages. |
| 104. |
| In case of errors, it should identify list of rows that have produced errors and should not load any rows from the flat file, till all the rows are error free. |
| 105. |
| Should support standard transport protocols like http, https, ftp, ftps, imap and smtp. |
FINANCE
| This section of Functional Requirements takes care of the Finance |
| Sup |
| Supported |
| No |
| Requirements |
| Sup |
| Cus |
| 3rd |
| Ns |
| Component |
| Comment |
FINANCE
FINANCE PROCESSES
Accounting Setup
| 1. |
| The system shall support Encumbrance accounting i.e.: Reserve (requisition), Commit(LPO/Call-off), Actualize (invoice) |
| 2. |
| Ability to setup accounts using the chart of accounts (COA) |
| 3. |
| Ability to setup pricelists with different versions |
| 4. |
| Ability to add pricelist to a budget holder (source of fund) to allow for zero value invoices for the third party (budget holders) |
| 5. |
| Ability to setup tax categories |
| 6. |
| Ability to setup tax and rates for each tax type |
| 7. |
| Ability to define accounting for each tax type |
| 8. |
| Ability to setup accounting calendar |
| 9. |
| Ability to define bank and bank accounts |
| 10. |
| Ability to define default currency |
| 11. |
| Ability to define new currency |
| 12. |
| Ability to define an account for currency |
| 13. |
| Ability to define currency conversion types |
| 14. |
| Ability to define currency conversion rates |
| 15. |
| The system to generate an output of all accounting entries |
for a user specified period
| 16. |
| The system to process, track, account and report on for the |
necessary range of currencies across all the modules
| 17. |
| The system to permit entry of free format text (e.g. in the case where the accounting personnel wants to provide additional information during posting of Journal entries, vouchers etc.) |
Account Payables
| 1. |
| The system shall be constrained to vote functions. |
| 2. |
| The system shall be constrained to vote heads. |
| 3. |
| Ability to define cost centers e.g. departments |
| 4. |
| Ability to use accrual based accounting |
| 5. |
| Ability to define banks and their accounts |
| 6. |
| Ability to use multiple currencies |
| 7. |
| Ability to define a base currency |
| 8. |
| Ability to perform currency conversion |
| 9. |
| Ability to capture GOODS RECEIVED NOTE - GRNs (Goods Receipt Note) |
| 10. |
| Ability to capture supplier/purchase invoice |
| 11. |
| Ability to capture create call off order (replaces the LPO) |
| 12. |
| Ability to create credit memo |
| 13. |
| Ability to create a Payment document |
| 14. |
| Ability to captured different payment methods including; cheque, EFT, cash |
Government Funding
| 15. |
| Ability to manage government funding in the system as Deferred Income |
| 16. |
| Ability to reduce liability as customer orders are served from the government fund already entered in the system |
Integration with IFMIS/ Banks (efts)
| 17. |
| Ability to automatically make payments through EFTs |
| 18. |
| Ability to integrate with IFMIS (Integrated Financial Management System) |
Accounts Receivables
| 19. |
| The system shall provide support for accounting for Third party handling fees billing |
| 20. |
| Ability to generate customer statements reflecting actual quantities and values of supplies of donor program stock delivered. |
| 21. |
| Ability to generate customer statements reflecting actual quantities and values of supplies of government program stock delivered. |
Fixed Asset Depreciation
| 22. |
| The System shall have an asset depreciation module. |
| 23. |
| The System shall have support to the following depreciation methods. |
[Straight Line, Reducing Balance ….]
| 24. |
| The System shall have the ability to link depreciation methods with Asset classes [furniture and fittings, Machinery & Equipment etc]. |
| 25. |
| The System shall capture depreciation start date. |
| 26. |
| The System shall generate a depreciation schedule. |
| 27. |
| The System shall accommodate revaluation of assets, done periodically (every 3 years). |
| 28. |
| The System shall provide capability to produce a depreciation report, per asset, asset class, or for all assets over a specified period of time. |
| 29. |
| The System shall provide capability to post depreciation expense to relevant accounts. |
Cash Management
| 30. |
| Ability to create bank accounts |
| 31. |
| Ability to perform bank reconciliation |
| 32. |
| Ability to automatically upload bank statements into the system |
Imprest Management Petty Cash
| 33. |
| Ability to create petty cash |
| 34. |
| Ability to set petty cash replenishment levels |
| 35. |
| Ability to requisition for petty cash |
| 36. |
| Ability to pay against a petty cash |
| 37. |
| Ability to maintain petty cash levels |
Per Diem
| 38. |
| Ability to define Per Diem Rates for employee job groups or classes |
| 39. |
| Ability to requisition for per diem |
| 40. |
| Ability to Pay against a per diem requisition |
Surrendable Imprest
| 41. |
| Ability to make Imprest requisition |
| 42. |
| Ability to pay against Imprest requisition |
| 43. |
| Ability to surrender Imprest |
| 44. |
| Ability to refund under-expenditure of Imprest during receipt |
| 45. |
| Ability to claim over-expenditure of Imprest |
| 46. |
| Ability to receive payment against an Imprest during surrender |
Donor Funding/Consignments accounting
| 47. |
| Ability to specify budget holder (NMS, Third parties/source of funds) for each product while making customer order entries |
| 48. |
| Ability to specify if a budget holder(source of fund) provides items for free (allowing related invoices not charge recipient facility(s)’ allocated budgets) |
| 49. |
| 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.) |
| 50. |
| Ability to reflect the actual value of this donor/partner stock in the accounts. |
| 51. |
| Ability to generate customer statements reflecting actual quantities and values of supplies of donor program stock delivered. |
Product setup requirements
| 52. |
| Ability to specify default budget holder (Source of Fund) for a product |
| 53. |
| Ability to specify default budget holder (Source of Fund) for a product category |
| 54. |
| Ability to add budget holders(sources of funds) to a product during setup |
| 55. |
| Ability to add budget holders(source of funds) list to a product category |
Reports
| 56. |
| Ability to generate and print a Trial Balance |
| 57. |
| The system to generate profitability reporting across units as well as profitability for the entire organization |
| 58. |
| Ability to generate the income statement (Profit and Loss Statement) |
| 59. |
| The system to support the generation of internal reports and transactional reports for each of the organizational units. It should be able to report at least on the following |
heads:
• By revenue/ expense heads
• By Asset/Liability heads
• By transaction types
• By status in the workflow process like draft, pending
| 60. |
| Ability to generate the cash flow statement |
| 61. |
| Ability to generate and print a balance sheet |
| 62. |
| The system to print / publish reports; and save them as viewable files in PDF, TXT, MS-Excel, XBRL and XML formats. |
| 63. |
| The system to export and extract data and graphical reports to spreadsheets / databases/ text/ presentations, etc for analysis and reporting. |
| 64. |
| Ability to generate statement of retained earnings |
| 65. |
| Ability to generate debtors analysis report |
| 66. |
| Ability to generate creditors analysis report |
| 67. |
| Ability to generate unpaid invoices report |
| 68. |
| Ability to generate payments by suppliers report |
| 69. |
| Ability to generate invoices by suppliers report |
| 70. |
| Ability to generate postings summary report by account |
| 71. |
| Ability to generate postings summary report by date |
| 72. |
| The system to support customizations of reports to |
company's needs, as per the details listed below:
• Ability to allow users to specify the exact layout of the required report including location of the fields, header, footer, page numbering, title etc.
• Ability to export extracted data and graphical reports to spreadsheets / databases/ presentations
| 73. |
| The system to provide context sensitive help to guide users |
to form the reports required by them
| 74. |
| The system to define a schedule for generation of each report. (e.g.: daily, weekly, monthly) |
| 75. |
| The system to define users to whom the report needs to be sent. The output format can be a paper or electronic Via |
email/internet/intranet etc.
| 76. |
| The system to be able to isolate and report on errors and exceptions. |
| 77. |
| The System shall provide a drill down capability from accounts total values to subaccounts and source documents |
| 78. |
| The system shall provide graphical/ easy to use workflow for approvals of accounting documents (Imprest/Invoices/ Payments etc). |
Asset Management
| 79. |
| Ability to capture Asset Receipt Note |
| 80. |
| Ability to capture Supplier invoice with items of type Asset |
| 81. |
| Ability to capture GOODS RECEIVED NOTE - GRN with items of type |
Asset
| 82. |
| Ability to register Asset acquisition cost |
| 83. |
| Ability to register an Asset into the System |
| 84. |
| Ability to register asset categories |
| 85. |
| Ability to define/specify parts of an asset |
Asset Maintenance
| 86. |
| Ability to register asset meter types (hours, days, mileage etc) |
| 87. |
| Ability to generate a maintenance schedule for assets |
| 88. |
| Ability to generate a work order/ a job card based on maintenance |
schedule
| 89. |
| Ability to generate a work order based on an asset breakdown |
(Preventative/)
| 90. |
| Ability to process work orders/ job cards through workflow |
| 91. |
| Ability to notify on items approaching maintenance based on the schedule |
Asset Location Management
| 92. |
| Ability to capture locations for assets |
| 93. |
| Ability to assign location to assets |
| 94. |
| Ability to assign/allocate an asset to a user |
| 95. |
| Ability to re-allocate an asset to/from a user |
| 96. |
| Ability to move an asset from one location to another |
| 97. |
| Ability to give a report of assets and their locations |
| 98. |
| Ability to import assets and their locations into the system |
PARTNER RELATIONS
Customer Relationship Management
| 99. |
| The system shall have the capability to maintain customer records |
| 100. |
| The data to be captured include: |
Customer basic data : Names, Code, Address, Contacts, budget allocation
| 101. |
| The system shall provide an Issues & complaints Management module. |
| 102. |
| The system shall also automate the issues and complaints workflow. |
| 103. |
| The system shall also allow for carrying out of simple surveys. |
| 104. |
| The system shall provide Events & Calendar Tracking |
| 105. |
| The system shall provide capacity for Logging of Calls/ Management |
of customer calls by CCRs
| 106. |
| The system shall provide capability SLA agreement monitoring |
| 107. |
| The system shall support Compliance Management e.g. Submissions to stakeholders, scheduling & calendaring of submissions, alerts for non-submission |
| 108. |
| Should track and manage follow-up communications with grant funding recipients: write-ups, monitor progress of contracts. |
| 109. |
| Ability to manage user interface based on user role/profile |
| 110. |
| Application security should allow administrators to determine access and visibility. |
| 111. |
| Ability to control report generation and visibility by user role/profile. |
| 112. |
| Ability to manage data visibility by role. |
| 113. |
| Ability to send mass communications to targeted contacts. |
| 114. |
| Ability to run analytics/reports on external users who submit comments and track that data against health commodities distribution. |
| 115. |
| WAREHOUSING AND RECEIPTS |
| 116. |
| 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
| 117. |
| The system shall support generation of delivery bookings for suppliers. (Suppliers inform NMS in advance on delivery & a booking is issued by NMS) |
| 118. |
| The System will link delivery bookings to purchase documentation i.e: Calloff/ LPOs, Supplier Contract |
| 119. |
| The System shall capture scanned supplier documentation on goods |
Delivery i.e(NDA Release/ DELIVERY NOTE/ Invoice/ Letter of Undertaking(Short shelf life items
| 120. |
| The System shall capture Goods Verification data i.e. Goods types, |
Quantity (Control) – flexibility, but max quantity delivered = quantity ordered Batch Nos/Expiry, Manufacturer, Country of Origin
| 121. |
| The system shall support capture of Quality Assurance review. |
| 122. |
| The system shall support goods receipt process Audit |
| 123. |
| The system shall provide capability to quarantine Stock |
| 124. |
| 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. |
| 125. |
| The system shall provide capability link Items to the palette on which they sit. |
| 126. |
| The system shall support cycle counts. This should be seamlessly embedded on the RF Guns. |
| 127. |
| The System shall support intelligent cyclic/ round robin/ random |
assignment of cycle counts tasks to pickers
| 128. |
| The system shall support intelligent warehouse zoning |
| 129. |
| Support intelligent Pick faces based on |
· Frequency of picks
· Volume
· Weight
· Item value
| 130. |
| The system shall support flexible item picks based on: |
· Batch Nos
· Manufacturer
· Country of origin
· Location [zone]
· Warehouse
| 131. |
| 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]
| 132. |
| The system shall support physical access controls based on assigned duties. Integration to access control systems is required. |
| 133. |
| The system shall provide BI dashboards for cycle counts variation |
analysis
| 134. |
| The system shall support Intelligent alerts and notifications for stock |
write-offs based on consumption rate, demand, AMC etc
| 135. |
| The system shall support Financial reconciliation of written off stock. Write-offs shall be based on similar |
principles as selling stock (FEFO/ FIFO)
| 136. |
| The system shall support Financial reconciliation of written off stock |
| 137. |
| The system shall support configurable Product expiry Prompts, alerts |
& notifications
| 138. |
| 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
| 139. |
| 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.
| 140. |
| The system shall link returned items to customer sales order |
| 141. |
| The system shall support bar coding of delivery documentation |
| 142. |
| The system shall support item costing and Supplier Payment on receipt of items. (Finance) |
| 143. |
| The system shall support intelligent stock movements (Replenishment |
waves) (Note: the stock movement feature should prevent allocations of stock while movement action is in progress/i.e. incomplete, and should not move allocated/reserved stock/i.e. stock already on pick) BI required to analyze movements
| 144. |
| The system should capture a graphical map of the warehouse. |
| 145. |
| The system shall provide Warehouse temperature & Humidity |
Monitoring
| 146. |
| The system shall provide temperature and humidity monitoring for delivery fleet. |
| 148. |
| The system shall support Pre stock Take Process including the |
following sub-processes
· Stock Take Planning
· Create a Stock Take Team
· Create A Stock Take Schedule/ Meetings
· Generate Stock Take Template [For capturing additional product information]
· During the stock take, Stock movements, picks, receipts are restricted (There shouldn’t be any open customer orders or receipts from suppliers). Close/ Finish all open transactions
· Lock up the system & Back up (Stock Take Mode)
| 149. |
| The system shall support Actual Stock Take Activities |
· Users generate stock count sheets. There should be flexibility in generation (by warehouse, zone, location, by product attributes): information include –product Code, Description, UOM, Batch number, Expiry Date where applicable
· Data capture
· The system shall generate a discrepancy report
· Repeat counts will be requested incase of discrepancy
· Stock take includes edits in batch nos, Expiry Dates
· The system shall produce a variance report
| 150. |
| The system shall support Post Stock Take Activities |
· Financial Reconciliation
· Post to Inventory
· Reopen the system for normal Operations
· Back up the system again
| 151. |
| INVENTORY MANAGEMENT |
| 152. |
| The system shall support creation of a product master file. |
Amongst the details that shall be captured include:
· Product code
· Description
· Alternative Code
· Substitutes
· Storage types
· Picking instructions
· Replenishment settings (max/min levels, pick location) etc.
· Package Sizes, Weight,
· Supplier Details
· Product categorization based on: stock category (Essential/Non-Essential, Analgesic etc.), Account
· Pickings settings – Picking area, min picking quantity, min
· batch picking, palette IDs
· Barcodes
· Picture of the product
· Required fields [Fields that must be captured when receiving the product] – {Country of origin, NDA Reg, LTR- Local Technical Rep, Manufacturer}
· Tag Product to Level of Care (HCI, HCII)
· Linkage btw same product with different UOM (100mg Panadol Vs 200mg Panadol) – UOM
· Dosage Forms
· Manufacturers
| 153. |
| The system shall support approval workflow for new products. Creator – SCO, HOD – Approval |
Finance & Quality
| 154. |
| The system shall support creation and management multiple warehouses/ Stores |
| 155. |
| The System shall support global Warehouse and Inventory settings |
setup
| 156. |
| The system shall support generation and importation of standard |
stock card templates to ease Loading of product data
| 157. |
| The product shall provide Intelligent Product Forecasting that take |
into account Pipeline stock/ Expiry/ Demand/ AMC
| 158. |
| The System shall trigger supplier replenishment alerts and |
notifications on the System and Email targeted to relevant departments/roles in the organization based on the Product Forecasting changes
| 159. |
| The system shall support Product Forecasting dashboard BI |
| 160. |
| The System shall integrate the Expiry Projections Report tool developed by NMS for expiry Forecasting. The System shall provide a dashboard on the BI environment for expiry forecasting. |
| 161. |
| The System shall support export/ import functionality for reports and |
dashboards into PDF/XLS/Word
| 162. |
| CUSTOMER ORDER RECEIPT & PROCESSING |
| 164. |
| The system shall include a customer self-serving portal |
| 165. |
| The system shall include importation of customer orders in various formats |
| 166. |
| The system shall support Notifications for non-submission, late submissions, receipt of all orders and acknowledgement on receipt of order. |
| 167. |
| The system shall tag all orders to delivery cycle |
| 168. |
| The system shall automatically support capability to group orders by facility, order types, cycle dates to enhance order processing and picking |
| 169. |
| The system shall provide order consolidation capability based of facility and order types. (Such orders will serviced as a unit) |
| 170. |
| The system should be able to consolidate orders from multiple facilities and select items to be delivered using cross docking or direct delivery methods. |
| 171. |
| The system should maintain correct information on the items delivered through the different methods. |
| 172. |
| The system shall support Encoding of orders. (Encoding involves determination of supply quantity based on customer procurement plan, availability of product amongst other Considerations). Amongst the information the system must include: |
· Product information- Code, Name
· Customer Order Qty – Captured in order entry
· Procurement Plan Qty (for the cycle) +-20% deviation allowed
· Year to Date budget consumption per item & remaining budget
· Year to Date Total Budget consumption.
· Quantity Encoded – Supply Quantity
· A Notes Field for each item whose qty ordered is different than that encoded
Ability to pick items based on:
· Batch Nos
· Manufacturer
· Country of origin
· Location [zone]
· Warehouse
| 173. |
| The system shall support automatic |
grouping/ranking of Orders to Encode
| 174. |
| The System shall support order control constraints based on products available to the facility (based on facility Levels and Budget Holders) |
| 175. |
| The system shall support order controls/constraints based on Procurement plan & Budget limits. (Note: During order capture, available budget to the facility(s) should only be reduced once the order is confirmed, however during encoding, the likely budget reduction can be displayed to facilitate the user to keep within budget available; The order processing should support individual, group custom order kits) |
| 176. |
| The system shall support Product Linkage based on pack sizes (UOM) |
Based on inventory forecasting intelligence [esp. Expiry data], the system shall prompt the user with other stock items under the same product but different UOM. E.g. Paracetamol 500mg tablet (UOM 1000) and Paracetamol 500mg tablet (UOM 500)
| 177. |
| The System shall have the capability to |
Present/select substitute products during creation/encoding.
| 178. |
| The System shall provide capability for different workflows based on parameters such as order types [Emergency, Scheduled etc.] |
| 179. |
| The systems shall support Real time End To End Order Processing Visibility to NMS stakeholders including: Online for customers, sales staff, procurement |
| 180. |
| The system shall provide indicative delivery dates to customers based on the order processing metrics. |
| 181. |
| The system shall provide real time proof of delivery capture (POD) |
| 183. |
| The system shall support prioritization of orders based on amongst other variables: order flagging, route Schedules |
| 184. |
| The system shall support Transport/ Journey Planning/ Route Planning [LPG, Vaccines] Linked to order picking |
| 185. |
| The system shall support assignment of journeys to trucks Based on Cargo properties (No of items, weight, volume) |
| 186. |
| The system shall support financing of Per diem for Drivers |
| 187. |
| The system shall support management of Third party logistics (Distribution type – Hub & spoke) |
| 188. |
| The system shall support automatic prompts/alerts to warehouse for |
new orders
| 189. |
| The system shall support Order Picking using RF guns. Blind Picking shall be supported (Pickers shouldn’t know to which facility the item goes) |
| 190. |
| The system shall support the order checking step once items have |
been picked
| 191. |
| The system shall support bulk picking capability [difference- picking |
zone?]
| 192. |
| The system shall support a conveyor system for delivery of items/cartons to marshalling area |
| 193. |
| The system shall produce all documentation required once all items |
have been received at the end of conveyor Documentation: Delivery Note, Invoices, Shipment Manifest, Job card for 3pl
| 194. |
| The system shall generate job cards for Third party Logistics (3PL) |
service provider (based on a journey)
| 195. |
| The consignment handed over to driver Trip Authorization form [formality] |
| 196. |
| The system shall support Fleet Management Monitoring of Fuel, Speed & location of fleet. Must be linked to asset management |
| 197. |
| The system shall support capture of Proof of Delivery (Documentation) Scanned into the system. The system shall utilize Bar-coding on delivery documentation to ease capture of POD documentation. |
| 198. |
| The system shall support Cross Docking. The system shall capture all relevant supplier documentation including: GOODS RECEIVED NOTE - GRN, Invoice, NDA release etc. |
The system shall support generation of Delivery Notes to the customer and capture Signed & stamped DELIVERY NOTEs once goods are delivered.
The system shall support Inventory management for cross docking (XD). Additionally the Cross Docking process should go through the normal pre-action data entry, requisite authorizations, quality assurance and pre-audit process and various logs should be able to log the returned item(s) for future review.
The system shall support traceability of items issued using cross docks by capturing & using item attributes such as:
· Batch numbers
| 199. |
| The system shall support Direct Delivery distribution method. The Direct Delivery process should go through the normal pre-action data entry, requisite authorizations, quality assurance and pre-audit process and various logs should be able to log the returned item(s) for future review. |
| 200. |
| The system shall support Returns inwards (Goods return process should be end to end, i.e. when returns are made, facility balances should be credited i.e. with credit memo, the stock quantity should be increased by returned quantity and the stock value should increase by the value of the returned item(s). Critical is that all tracking information of the returned item(s) must be restored and accurate, i.e. budget holder, expiry date, batch number, etc.) Additionally the returns should go through the normal quality assurance and preaudit process and various logs should be able to log the returned item(s) for future review.) |
| 201. |
| The system shall support Reporting/ BI. Reports required include: |
· Order Aging Report
· Open Orders
· Closed Orders
| 204. |
| 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
| 205. |
| Monitoring of Deliveries against delivery Schedule |
| 206. |
| Reporting & Visualization |
| 207. |
| Customer Procurement Plans |
| 208. |
| 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)
| 209. |
| The system shall provide Capability To Aggregate All Customer procurement plans to national Procurement plan |
| 210. |
| Capability to change facility/Customer procurement plan |
| 211. |
| The system shall have capacity for Generation of Customer Procurement Plan templates. Generation of customer procurement plan templates must considerations: |
· Items Available to Facility Level
· Budget Available to facility
· Historical Ordering behavior & Budget
· Ceiling: (Budget allocation -+ Deviation)
| 212. |
| Ability for Customer To Download Template Procurement Plans in various formats. |
| 213. |
| 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)
| 215. |
| 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.
| 216. |
| 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
| 217. |
| The System shall provide capability to capture Service Types provided by NMS which shall include: Procurement, Storage & Distribution, Clearing Services (PSDC) services. |
| 218. |
| 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
| 219. |
| 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
| 220. |
| Ability to derive operations budget total from the aggregated charges. |
| 221. |
| Capture Facilities and associate them to their respective levels of care. |
| 222. |
| Ability to define operations Vote heads; Finance Department, Human |
Resource Department, Customer Service and any other department.
| 223. |
| Ability to define maximum budget allocation (ceiling) for each operations Vote heads; this will be the basis of the unit (department) plan. |
| 224. |
| The system shall produce Budget estimate report. |
| 225. |
| Ability to produce report showing budget distribution per Vote heads |
& functions. (The different levels and their amounts).
| 226. |
| Ability to produce report showing budget caps/ceiling per facility. |
| 227. |
| Ability to produce report showing budget allocation for each facility |
for a given vote function
| 228. |
| Ability to export ALL reports to various formats |
| 229. |
| Entity Procurement Plan |
| 230. |
| The system shall allow creation of departmental procurement plans |
1. Serial No
2. Product Description
| 231. |
| The system shall enable consolidation/aggregation of procurement plans |
| 232. |
| The system shall have capability for automated Approvals [Workflow] Contracts Committee Approval, |
Management/ Board Council Approval
| 233. |
| Export/ Import Capability for procurement plans |
| 234. |
| Procurement Controls: procurement of items not included in the procurement plan should be denied. |
| 235. |
| REQUISITION TO PAYMENT |
| 236. |
| Requisitions (Without Framework Contracts)/ Contracting Process |
| 237. |
| 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
| 238. |
| The System should provide the ability to check if a contract exists for |
the items being requisitioned
| 239. |
| Ability to create tendering/bidding document for items that do not |
have existing contracts
| 240. |
| Ability to specify different methods of procurement including tendering, request for quotation and others |
| 241. |
| Ability to Choose a method of procurement (threshold, category – |
trading/non trading)
| 242. |
| Ability to add Short Listed Bidders (Prequalification of Suppliers) to a |
bid document
| 243. |
| Ability to add a listing of Participants of procurement [People involved |
in Creation of bid document]
| 244. |
| Ability to add tender evaluation members to a bid document |
| 245. |
| Ability to set and add Cost of bidding document |
| 246. |
| Ability to forward document to contract committee for review & |
approval
| 247. |
| Ability for the Tender Committee to approve or reject based on |
existence of issues (Returned to procurement)
| 248. |
| Ability to Communicate to shortlisted bidders by email in restricted |
tenders (Other communication methods should be supported)
| 249. |
| Ability to communicate to bidders through media in open tenders |
| 250. |
| Tender Documents Collection: Capture details in prescribed Forms |
| 251. |
| Ability for bidders to collect bid documents (Bid collections documentation) |
| 252. |
| Ability to capture details of persons collecting bid documents or addendum |
Ability to capture details in prescribed Form (Pre-bid meetings)
| 254. |
| Ability to capture pre-bid meetings |
| 255. |
| Ability to capture clarifications of pre-bid meetings |
| 256. |
| Ability to create addendum and send to bidders |
| 257. |
| Bid Closing/ Opening Bids/ Receiving Bids: Ability to capture the details in prescribed Form 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) VI. Name of officer
Ability to specify documents required in the tender evaluation process
| 259. |
| Ability to check against documents availability in the evaluation process |
| 260. |
| Ability to capture evaluation report. |
| 261. |
| Ability to send evaluation report to the contracts committee [Workflow] |
| 262. |
| Award By Contracts Committee |
Ability for the contracts committee to approve/reject an award.
| 263. |
| Ability to produce/capture Minutes of contract committee. |
| 264. |
| Notice To Best Evaluated Bidder |
Ability to define award notice display period as specified by law
| 265. |
| 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
| 266. |
| Ability to send award information to all bidders |
| 267. |
| Ability to define a limit value of bid to send to the solicitor general |
[Workflow]
| 268. |
| Ability to alert/notify procurement to send award documentation to |
solicitor general based on the value specified above
| 269. |
| Ability to generate notification of award {Email Winning Bidder} |
| 270. |
| Ability to issue notification award {Email Winning Bidder} |
| 271. |
| Ability to stop the bid process if the solicitor general rejects the |
Process.
| 272. |
| Ability to capture Solicitor General’s Decision regarding contract award. |
| 273. |
| Ability to receive acceptance letter and invoice for framework contracts |
| 274. |
| Ability to receive acceptance letter, proforma invoice and bid security for one time/ lump sum contracts |
| 275. |
| Contract Signing: Ability to capture Contract Manager Appointed by Accounting Officer and selected by user department |
| 276. |
| Ability to capture Contract Implementation Plan (Form) filled by |
Contract Manager
| 277. |
| Contract Monitoring: Ability for procurement to monitor contract implementation |
| 278. |
| Ability to capture expiry of contracts |
| 279. |
| Ability to capture delivery schedules on the contract |
| 280. |
| The shall support Generation of Call off orders (Call-off order converted into PO) |
| 281. |
| The system shall enable Call off orders to be generated based on: |
1. A supplier
2. Products/ Items
| 282. |
| 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
| 283. |
| The system shall validate Call-offs based on validity of Contracts Ensure contract is active (check contract |
period & contract status)
| 284. |
| The system shall validate Call-off based on availability of funds Ensure there’s funds availability before |
approval of call-off – Procurement plan figures
| 285. |
| The system shall enable reallocation of funds between products and product Categories. |
| 286. |
| The system shall 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
| 287. |
| Prequalification of Suppliers |
| 288. |
| The system shall in a Prescribed Form – Prequalification Bids (List of suppliers who requested for and were issued with the prequalification document) |
| 289. |
| The System shall provide capability to capture supplier prequalification approval form. (Prescribed Form) |
Details in Form 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 prescribed form)
· Declarations by PDU & Contracts committee
· Date of submission to contracts committee
Prequalification Constraints Classes A – High Value High Volume B – Low Value, Low Volume Prequalification Period expiry 3yrs
| 290. |
| The system shall provide a configurable, graphical workflow process to enable approvals/authorizations required for this process. |
| 291. |
| The system shall provide capability to export the details of the prescribed form using NMS specified template |
| 292. |
| The System shall provide capability to generate a Prequalification |
Assessment from the aggregated/collated details of submitted prequalification requests.
Details of the Prequalification
Evaluation shall include:
· Procurement Reference details(Copied from prescribed Form)
· Code of Procuring & Disposing Entity
· Type of Service (Works/Supplies/Non-consultancy services)
· Financial year
· Sequence Number (System Generated)
All submitted prequalification requests (Form X) are assessed in a single assessment document (Form Y), therefore, the system requires the capability to collate information from form X into form Y requirements.
| 293. |
| 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
| 294. |
| Contract Management & Monitoring |
| 295. |
| The System shall provide capability to capture supplier contract information and Performance indicators. Performance indicators will include: Timelines in delivery (from Calloff dates & Delivery dates), order fulfillment capability, etc |
| 296. |
| The system shall have capability to export contract performance |
information in a format specified by NMS
| 297. |
| The system shall provide integration to Procurement Performance |
Measurement System (PPMS)
| 298. |
| The System shall provide basic performance reporting based on the |
performance indicators specified
| 299. |
| The System shall provide capability for integration with a BI tool |
| 300. |
| The system shall allow creation of a list of items to dispose [template |
form to be proposed]
| 301. |
| The system shall capture details of the valuation report |
| 302. |
| 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 |
| 303. |
| The system shall provide capability to support different disposal |
method…
This is the start of the file's text. The full file is on GovTribe.