Facility Management
Goals/Scope
- The goal of this requirements page is to document the user stories associated with Facilities management. Facilities management is defined as enabling the administrator to create, assign, and edit facilities in OpenLMIS so that the setup of users includes relating facilities to their roles.
- Scope: This feature includes stories on:
- Creating a new facility
- Editing an existing facility
- Assigning a facility to a user, Supervisory Node
- Associate supported programs to a facility with start dates
- Adding and editing programs and schedules to a facility
- Add and edit Facility FTP settings
- Scope: This feature includes stories on:
Background
The administrator is the only user that will create, assign, and edit facilities. Facility data is gathered prior to beginning configuration of OpenLMIS. Facility types are predefined and necessary for facility management.
Assumptions
- We will use the predefined facilities, facility types, geographic zones, programs, and schedules that exist in 3.0 to complete development for this feature.
- We will reuse 2.0 UI screens with minor updates to enhance data entry flow.
- The existing 3.0 schema supports Facilities data elements to complete a new setup or edit a facility.
- The "system" referenced is OpenLMIS.
- The only way to create a new facility type is via upload. There is no admin UI page for creating a new facilty type.
User Stories
Diagrams
Dependencies
Description | Link |
---|---|
Open Questions
Below is a list of questions to be addressed as a result of this requirements document:
# | Question | Outcome | Status |
---|---|---|---|
1 | Is the designation for Service Delivery Point needed? Per the 2.0 Configuration Guide: "The facility is SDP attribute is a flag to indicate whether or not this facility is a service delivery point. The setting for this flag does not control whether or not a facility can submit requisitions or receive deliveries, but is useful for sorting facilities when generating reports." Which reports? SDP is not in current v3 schema and would need to be added to whole stack per Chongsun. | Mary Jo Kochendorfer (Deactivated): I think it is okay if we leave this off for now. | |
2 | Once a facility has been given a "Go-Live Date" should this be made uneditable? Change "Go-Live" in UI to say Operational Date, or Effective Date? | Mary Jo Kochendorfer (Deactivated): What is the impact of making it editable? I think it is okay to leave this editable since someone may accidentally put the wrong date. Since the Admin is the only making edits I think it would be okay. I'm not partial to which wording to use. We should check if this date is referenced for reporting. | |
3 | Once a program Start Date has been entered, should this be made uneditable? | Mary Jo Kochendorfer (Deactivated) : I feel the same way as above. | |
4 | Facility codes can change per business use cases, once they've been created. How will this be tracked and managed? This appears in user dropdown selections and some reports (R&R). What is the desired behavior? What is the behavior if the process for changes is a batch upload for multiple facility updates? (example, facility changes are completed in a batch process in a UAT environment, reviewed, and then scheduled to run in production after it has been approved) |
Out of Scope
- Configuration of facilities via csv upload
- Assigning Requisition Groups is a separate feature (TBD)
- Assigning Products to a Facility type is a separate feature (TBD)
- Editing associated programs for a facility (do we need audit logging for this?)
- Audit logging for changing Facility from Active to Inactive
OpenLMIS: the global initiative for powerful LMIS software