The OpenLMIS requisition process uses a supervisory hierarchy that is routed by requisition groups. This is a guideline to help you understand the hierarchy that becomes a blueprint for your configuration.

What you need to setup a hierarchy:

 

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: