Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added screens

This page documents the software requirements and outlines the integration for the OpenSRP-OpenLMIS proof of concept that will be demonstrated to GAVI the week of 26th March 2018.

...

This section was copied from the previous page for reference. This section defines the minimum functional workflows for the proof of concept demo. Stretch activities are clearly marked with (Stretch)

  1. (Current Functionality) OpenSRP Android Client Demo prep to show current functionality
    • The OpenSRP user will login to the stock management module to see the current number of vials available for the antigen
    • The OpenSRP user click the card for the antigen and touch the Issued button to record an adjustment in the stock of that antigen
  2. (New) OpenSRP Android Client Requesting Stock
    • The OpenSRP user is already at the Stock Management Module screen
    • The user will touch a button to request stock based on Ideal Stock Amounts
      • A message will appear verifying that the user is requesting stock "Please confirm that you would like to request stock based on your Ideal Stock Amounts"
    • The device syncs with OpenSRP Server
    • NiFi queries the OpenSRP Server endpoint every 'n' seconds and identifies that a new stock request has been received
      • How do we tell what's "new"? Are new stock requests any with a created data newer than the last created date we saw on the endpoint?
    • NiFi performs internal business logic to map the stock request to the facility, user and ideal stock amount (ISA)
    • NiFi pushes an order to the OpenLMIS Orders API endpoint in the Fulfillment Microservice. An Order number is returned to NiFi.
      • Not sure NiFi can receive an order number, what is it supposed to do with it?
    • OpenLMIS user logs in to verify the order was created
  3. (Current Functionality) OpenLMIS Demo to convert Order to Shipment
    • OpenLMIS user walks through the order fulfillment process
    • A shipment is created
  4. (New) OpenSRP Android Client Receiving Shipment
    • NiFi queries the OpenLMIS Shipments API in the Fulfillment Service to see if a new shipment has been generated
      • (Note: Should this be the API endpoint, or should we query the Proof of Delivery Endpoint?)
      • How do we tell what's "new"?
    • When a new Shipment is identified, NiFi queries the Shipment/{id} API endpoint in the Fulfillment service to get the shipment details
    • NiFi performs business logic on the Shipment details to convert it to the appropriate JSON format required by OpenSRP
      • Does this logic require any data not received from the shipment/{id} endpoint?
    • NiFi posts the JSON to the OpenSRP Server
    • OpenSRP Server receives the shipment information
    • On a regular schedule, OpenSRP Android Client Syncs with the OpenSRP Server
      • A new shipment is received
      • A notification is generated in the Stock Management Module's Shipment section (new section)
    • OpenSRP user touches the shipments section in the stock management module and they are redirected to a page showing that a shipment is available
    • OpenSRP user touches the shipment and they view details of the shipment
    • User can accept shipment
    • (Stretch) User can adjust the amounts of each orderable and touch save
      • On Save action, the antigen amounts update on the tablet
    • OpenSRP Android client will sync with OpenSRP server
    • (Stretch) NiFi Queries OpenSRP Server on a regular schedule for Proof of Delivery
      • What is the proof of delivery?
    • (Stretch) NiFi performs the appropriate business logic to accept the proof of delivery and creates the appropriate JSON to post to OpenLMIS
    • (Stretch) NiFi posts the Proof of Delivery to the OpenLMIS Proof of Delivery API endpoint in the Fulfillment Service.

...

This section includes a unified view of the UI enhancements that are required to deliver both features. We will need to create the following:

  1. A new "Orders" view that has two actions:
    1. View Orders
    2. New Order Button
    3. Shipment(s) Button
    Shipment(s) View
  2. Orders view
    1. Allows a user to view all historical shipmentsorders, shipments that are available and completed orders
  3. Shipment Receipt View
    1. Allows a user to receive a shipment and apply it to their stock on hand

Screens

PDF
nameMock up for OpenLMIS Proof of Concept_5_Mar_2018.pdf


New Order Button

  • Business Logic
    • When the button is pushed, a confirmation dialog will pop-up with the text "Please confirm you wish to order stock"
      • UI Fields "Confirm" and "Cancel"
      • Business Logic:
        • When "Confirm" is touched, the order stock request is submitted
        • When "Cancel" is touched, the user returns to the screen

ShipmentOrders(s) View

This view shows a list of all orders, shipments and completed that have been sent to from this facility. The user can only touch "new" shipments items in the shipments dropdown that haven't yet been accepted

...

  • This screen should have a visual indicator that shows a new shipment is available to be received

...

.

Shipment Receipt View

This view allows users to take action on the shipment and apply it to their stock on hand.

  • An A "AcceptReceive" view that displays the stock items to be received
    • This view includes the detail by antigen type (OPV, PENTA, etc).
    • Fields:
      • Stock Item - This shows the name of the stock Item (OPV)
      • Quantity Received Ordered - This shows the quantity received (Integer)
      • Unit Shipped - This shows the unit number of measure vials ordered (VialsInteger)
      • Doses - This shows the calculated number of doses in the shipped Quantity
    • (STRECH GOAL)
      • A stretch goal for this screen would be to allow users to adjust the amount received. The form would be populated by the amount in the server, but the user could increase or decrease each stock item with actual values.
    • Actions and Business Logic:
      • Accept Receive - When the user touches "AcceptReceive" the following business logic is performed
        • The Receipt is updated with "acceptreceived" and "acceptDateTimereceivedDateTime" information
        • Each item in the receipt creates a stock item event in the android client
          • The date of the event will be automatically populated to the current Date and Time
          • Each stock item event will be from "Other" with the name of the sending facility saved
          • The amount received will be added to the current stock on hand
          • The order will no longer display in the shipment section of the "View Orders" screen
        • The user will be redirected to the stock card control screen where they will see the new values.
      • Cancel - When the user touches "Cancel" they are returned to the previous screen

...