Supervisory Hierarchy

What you need to setup a hierarchy:

• Supervisory Node: A supervisory node is not a physical entity or location, but rather a sort of logical control point through which requisitions are routed for review and approval, and must always exist for a requisition to be approved. Supervisory nodes are thus a mechanism that OpenLMIS uses to control the workflow of requisitions, and to manage related rights for individual users of the system. Typically, a user would be given review-and-approval rights for requisitions passing through a particular supervisory node, and these rights could be assigned for one program or multiple programs that the requisition group handles.
• Requisition Group: A Requisition Group is a way to manage the replenishment process for multiple facilities or approval hierarchies. It is a grouping of facilities that have characteristics in common.
  • run the same programs or subsets of programs
  • operate individual programs on the same replenishment schedule
  • rely on the same supervisory hierarchy for review and approval of their requisitions
  • rely on the same warehouse to fill their orders for each program
• Roles/Rights: Users' permissions in OpenLMIS are based on assigning them to one or more roles. Roles in turn, are custom-configured by an administrator, and are combinations of one or more rights available in OpenLMIS. Rights relate to individual actions that a user can take, such as view a report, or create a requisition.
• Processing Schedule: OpenLMIS supports customizable schedules that define the periods or calendar intervals at which facilities are replenished. Each schedule is typically divided into uniform periods, such as months or quarters. OpenLMIS supports having multiple schedules tailored to how each program and/or geographic region is managed.
• Facility: OpenLMIS supports facilities that function as Service Delivery Points, and facilities that function as warehouses or "supply depots" to replenish other facilities. A single facility can be an SDP or warehouse, or both an SDP and a warehouse.
• Programs: OpenLMIS can handle multiple Programs operating at once. Each Program has a specific set of Orderables, a complex configuration including Requisition Form settings and Program-specific user permissions, and a network of Facilities that are participating in the Program.

Important rules that determine how many Supervisory Nodes and Requisition Groups you need to create:

A)    A facility must be associated with a Supervisory Node and a Requisition Group in order to complete the requisition process for the facility.

B)    A Requisition Group must exist and be associated with a Supervisory Node.

C)    Only one Supervisory Node to one Requisition Group. If there one facility is in multiple Requisition Groups, then another Supervisory Node must exist.

D)    If separate programs at a facility require different tiers of approval, or a different order of approval, then you need another Requisition Group.

E)    A Supervisory Node is a hierarchical tree. There can be more than one Supervisory Node in a requisition process if more than one approval is required, and this is set up by adding a Parent Node that routes the requisition up to the next approver.

F)    One Supervisory Node, associated with a Requisition Group, can contain multiple facilities.

G)   In order to process approvals, a Program must be associated with a SN and a corresponding role or the user will not have the rights to approve.

Hierarchy Diagram

Explanation of the diagram:

• There are four Supervisory Nodes because rules A, C, E. There are two single level approvals SN01 and SN02, and there is one two-tier approval supported by SN03.1 and the parent is SN03.
• There are three Requisition Groups because rules B, C, D.
• There are two different Processing Schedules at one facility (DH02) so rule C applies here because Supervisory Node 02 is already associated with Requisition Group Blue.