1. Introduction

1.1 Purpose

This document captures the business requirements for the Inventory Management module spanning the admin Portal and camp-level local servers (camp laptops), the synchronization between them, the backend APIs supporting the StopTB drug master and local stock management. It also covers the creation of a National → State → District → Block hierarchy mapped to the StopTB programme states, level-based user management with role-wise privileges, and a one-time bulk upload of items into the Item Master using an Excel template.

1.2 Scope

• Creation of a four-level hierarchy (National → State → District → Block) mapped to the 10 StopTB programme states
• Mapping of existing stores to hierarchy nodes
• User creation at each level, with each user mapped to one hierarchy node and one role
• Role-wise privileges, controlling what each user can view and do based on their level and role
• Data visibility restricted to the user’s own node and the levels below it
• One-time bulk upload of items into the Item Master using an Excel template, with validation and an error report
• Audit log of hierarchy, user and bulk upload actions

2. Required Changes in AMRIT Inventory Management Module 

2.1 Purpose of This Section

The existing AMRIT platform already has a live Inventory Management Module, with an Admin Portal for master-data configuration. Highlighting the sections that will get added to the flow : 

• Supplier Master (No change in the form)
• Manufacturer Master (No change in the form)
• Pharmacological Category Master (No change in the form)
• New Form : Device Master - Refer Section 2.2.B
• Item Category Master (Can include category name like X-Ray machine, PPE kit)
• Unit of Measure Master (No change in the form)
• Item issue method config (No change in the form)
• Expiry date alert config (No change in the form)
• Item Master (Changes suggested) - Refer Section 2.2.A
• New Function: Bulk Item Upload (one-time, via Excel) – Refer Section 2.2.J
• New Form : Device Inventory - Refer Section 2.2.C
• New Form : Device AMC/Warranty (linked to Device Inventory) - Refer Section 2.2.D
• Facility type master 
• Main store and substore
• New Form: Node to Store Mapping – Refer Section 2.2.G
• Item to Store Mapping
• Item to facility mapping
• New Form : Device to Camp/Store Mapping - Refer Section 2.2.E
• Van/parking place to store mapping.
• User Management (Changes suggested) – Refer Section 2.2.H
• New Config: Role & Privilege Matrix – Refer Section 2.2.I

This BRD is not proposing a new module from scratch - it is defining the changes required on top of what already exists. This section exists specifically to answer that question for the Admin Portal component, where all inventory master data is configured and from which it synchronizes out to various service line.

2.2 Section wise Detailing 

2.2.A. Item Master (existing form, changes only)

Item Type stays a two-way radio (Medical / Non-Medical) - Device is deliberately not a third Item Type; it is handled by the new masters in Tables 2.3.2 & 2.3.3

2.2.B. Device Master (NEW)

Generic device catalog, e.g. "Truenat Device," "X-ray Device," "Glucometer." Consumables tied to a device (e.g. glucometer strips) are not here - they stay in regular Item Master.

2.2.C. Device Inventory (NEW)

Item Master → Device Inventory (NEW) — the specific, physical units owned (e.g. this facility's actual glucometer unit).

2.2.D. Device AMC/Warranty (NEW, separate form, linked to Device Inventory)

2.2.E. Device to Camp/Store Mapping 

2.2.F. Hierarchy Node Master

This form defines the four-level hierarchy (National → State → District → Block) that the inventory module currently lacks. There is one National node, with the 10 StopTB programme states under it. Each State has its districts under it, and each District has its blocks. Every node will later be linked to a store (Section 2.2.G), and users are mapped to these nodes (Section 2.2.H).

Rules

• Only one National node can exist.
• National Admin can create and edit State nodes. State Admin can create and edit District and Block nodes only within their own state.
• A node cannot be inactivated while active users are mapped to it.
• A node cannot be deleted once created. It can only be inactivated.

2.2.G. Node to Store Mapping

This form links each hierarchy node to a store in the existing Main Store / Substore master. Existing stores, stock and reports keep working unchanged. Each node gets one main store, and Blocks can also have substores.

Rules

• Every Active node must have exactly one Active Main store before users can be mapped to it.
• National Admin can map stores for National and State nodes. State Admin can map stores for District and Block nodes within their own state.
• Changing a node’s Main store keeps the old mapping as Inactive, so the history is kept.
• A store cannot be unmapped while it holds stock. This check applies once stock transfer is introduced.

2.2.H. User Management (existing form, changes only)

The existing user creation form gets new fields so that each user is mapped to one hierarchy node and one role. The node controls what data the user can see: their own node and everything below it. The role controls what the user can do (Section 2.2.I).

Rules

• An admin can create users only at their own level or below, and only within their own hierarchy. National Admin can create users at any level. State Admin can create users only for their own state and the districts and blocks under it.
• Each user is mapped to one node and one role.
• When a staff member is transferred, the admin re-maps the user to the new node. The old mapping and all transactions done under it are kept.
• Inactivating a user does not delete their past transactions.
• After login, the user sees data only for their own node and the nodes below it. This restriction must be enforced in the backend APIs, not only on screen.

2.2.I. Role & Privilege Matrix (NEW)

This config defines the roles available at each hierarchy level and what each role can do. Super Admin can edit the matrix. The defaults are below.

Roles

Privilege Matrix

Y = allowed for all nodes, Sub = own node and nodes below, Own = own node only, – = not allowed.

Rules

• A role can only be assigned to a user at a matching hierarchy level. For example, State Admin can only be assigned to a State-level user.
• A user can never see or select a node outside their own hierarchy in any dropdown, report or API.
• Privileges for stock transfer (dispatch, receipt, block stock entry) will be added to this matrix when that BRD is taken up.

2.2.J. Bulk Item Upload (One-time activity)

This function lets National Admin load the full item list into the Item Master in a single upload, instead of entering items one by one. Items uploaded at central level apply to the national store and all StopTB states. The template columns match the Item Master fields in Section 2.2.A, and the same mandatory rules apply. Medical-only columns can be left blank for Non-Medical items.

Excel template columns

Upload process

1. National Admin opens Bulk Item Upload and downloads the Excel template. The template contains the column headers, mandatory columns marked with *, dropdown lists for master values, and one sample row each for Medical and Non-Medical.
2. Admin fills in the items and uploads the file (.xlsx only, max 5,000 rows and 10 MB).
3. The system validates every row and shows a preview with counts of valid rows, error rows and duplicate rows.
4. If there are errors, the admin downloads an error file. It contains the original rows plus an “Error Reason” column, so the admin can correct the rows and re-upload.
5. The admin clicks Confirm. Nothing is saved if any row has an error (all-or-nothing).
6. The system saves the items and shows a summary of rows added. The upload is recorded in the audit log along with the uploaded file.

Rules

• Only Super Admin and National Admin can use Bulk Item Upload (Section 2.2.I).
• Column headers and their order must match the template exactly, otherwise the file is rejected.
• Dropdown values must match existing master values. Matching is case-insensitive.
• An Item Code that already exists in Item Master is rejected as a duplicate. This upload adds new items only and does not update existing ones.
• Master values used in the file must already exist, for example Manufacturer, Category and UOM. Add any missing masters before uploading.
• Items added through bulk upload can be edited later through the normal Item Master form.

3. Reports & Audit

These reports cover the hierarchy, users and bulk upload. Each user sees data only for their own node and the nodes below it. All reports can be exported to Excel and PDF.

3.1 Reports

3.2 Audit Trail

Rules

• The audit log is read-only and cannot be edited or deleted by any role.
• The audit log is kept for at least 5 years (to be confirmed with the programme team).
• Super Admin can view the full audit log. National Admin and State Admin can view it only for their own node and the nodes below.

Format of exising inventory: