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:
- 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.
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 associated with a SN and a corresponding role or the user will not have the rights to approve.
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 so rule C applies here because Supervisory Node 02 is already associated with Requisition Group Blue.