VLMIS Manual
Administration

Maintenance

Manage products, product types, suppliers, the store hierarchy, and system settings.

Who can access this

Administrator role only, which in practice means central store staff.

Overview

Maintenance holds the master data everything else depends on: the product catalog, product categories, suppliers, the store hierarchy that decides who requests from whom, and system settings.

Tabs

  • Products: the product catalog.
  • Product Types: product categories (Vaccines, Diluents, Supplies).
  • Suppliers: supplier contact records.
  • Store Hierarchy: build and maintain the VLMIS supply hierarchy from the DHIS2 organisation units.
  • Settings: DHIS2 refresh, TRVST toggle, endpoint and device information.

Products

Each product carries a name, its product type, an HMIS code, a free-text description, and three flags that change how the rest of VLMIS treats it:

  • VVM Applicable: whether batches of this product carry a Vaccine Vial Monitor; only then do VVM stage fields become selectable in Arrivals, Distributions, and Issuing.
  • Expiry Date Applicable: whether batches must carry an expiration date.
  • Is Campaign Product: campaign products are excluded from the monthly consumption average shown on requisitions (they report zero), since campaign usage would distort routine consumption.

Products can be added, edited, and deleted from the table. A duplicate name is rejected ("product already exists").

Delete with care

Deleting a product is confirmed with a dialog and cannot be undone. Only delete entries created by mistake; a product that already has stock or transaction history should stay in the catalog.

Product Types

The categories products belong to, typically Vaccines, Diluents, and Supplies. Every product picker in the app filters by product type first, so keep this list short and stable.

Suppliers

Supplier records used when registering batches on the Arrivals page: name, contact person, phone, email, country, and city.

Store Hierarchy

VLMIS holds two separate hierarchies over the same organisation units, and this tab is where they meet:

  1. The HMIS (DHIS2) hierarchy: an exact replica of the national DHIS2 organisation unit tree (country, provinces, districts, facilities). VLMIS imports it and never edits it; it is the source catalogue of facilities.
  2. The VLMIS store hierarchy: the supply chain tree that VLMIS actually uses. It records, for each store, which store is its supplying parent. This is what decides where a facility's requisitions go and where its returns come back to. It starts empty: administrators build it by attaching facilities from the DHIS2 replica to their supplying parent.

The two do not have to match. A facility's administrative parent in DHIS2 (its district) is often also its vaccine supplier, but the store hierarchy can wire any facility to any parent store.

The tab shows three trees:

  • HMIS Hierarchy (left): the DHIS2 replica; tick one or more facilities to attach.
  • Store Hierarchy (middle): the current supply tree, rooted at the central store; pick exactly one store to be the new parent.
  • Detach Store (right): the same supply tree; tick stores to detach.

Move Organization Units attaches every ticked facility to the chosen parent. Moving also re-parents a store that already had a parent, which is how a facility is transferred from one supplier to another. Detach Stores removes the ticked stores from the supply tree; a detached store keeps existing in the DHIS2 replica but no longer has a supplier.

The hierarchy drives operations directly

A store with no parent cannot create requisitions or returns (its users see "Your store is not mapped to any parent store"). The central store itself can never be moved or detached ("Main Store is not removable"). Re-parenting a store redirects its future requests and returns immediately; in-flight orders keep their original sender and receiver.

Settings

  • Language: switch the interface language (English/French).
  • Organization Units, Refresh from DHIS2: fetches the full DHIS2 organisation unit list and adds whatever is missing locally. Existing units are never overwritten, and a unit whose parent is not yet known locally is skipped. The result summary shows exactly what happened: total from DHIS2, processed, added, skipped existing, skipped missing parent. Run this whenever new facilities were created in DHIS2 so they become visible in VLMIS (for the store hierarchy and for user creation).
  • Synchronization: read-only view of the eTracker data sync schedule and the last sync time.
  • DHIS2: the DHIS2 API URL this VLMIS instance is connected to (read-only, set by the server configuration).
  • TRVST Verification: turn UNICEF TRVST product verification on or off for the whole system. Switching it reloads the app so every feature gate picks up the change; with it off, the TRVST tabs and scanning integration on Arrivals disappear. See TRVST & ScanBridge.
  • Device: information about the machine and browser you are on (user agent, operating system, device ID) plus the longitude and latitude used for TRVST geo reporting.

Screenshots and step-by-step walkthroughs to be added.

On this page