Interface - Mobile POD
Goals/Scope
To allow data on delivery or rejection of supplies to be entered into OpenLMIS in a user friendly way which links with order or shipment data. This will facilitate monitoring and follow up of breaks or bottlenecks in the supply chain.
Status in eLMIS: Can record deliveries but not rejections, but not linked to orders or shipments, and feature not in use. Also dealt with in ILS Gateway Transport Module
Status in OpenLMIS: Can record deliveries but not rejections, no mobile application, not linked to orders or shipments, and data not sent back into ERP
Priority: High
Background
Currently in both eLMIS and OpenLMIS there is a feature to record deliveries as they occur (called the “manage the point of delivery” feature). Deliveries, but not rejections, are recorded. However, this data is not linked to order or shipment data, in other words, it is entered independently instead of “ticking off”, or amending as necessary, order or shipment data. This has caused the feature not to be used in Tanzania.
If changes are made to an order after it is in the ERP when shipments are prepared and dispatched or when goods are received, eLMIS does not receive any information either entered by users or imported from the ERP. The “point of delivery” functionality in eLMIS, which was designed for entering data on products delivered, is not currently in use. The reason for it not being in use is because it is not user friendly, requiring re-entering details of products received rather than “checking them off” the order submitted (or shipped). This means that the supply chain is not visible to facilities and others without access to the ERP after the requisition-to-order point.
Merging the Shipment Visibility into this since it is a pre-requisition to having shipment data available on a mobile.
Assumptions
- Shipment File Import is implemented and this offline mobile feature adds to the usability
User Stories
# | Title | User Story | Label | Importance | Notes |
---|---|---|---|---|---|
1 | Manual shipment receiving entry | As a facility user/driver, for each delivery shipment that arrives, I want to pull up the quantity issued (shipment data) and record the following for each product:
| eLMIS | Must have | from MJ: Elaine Baker, Alfred Mchau, Alpha Nsaghurwe, Nsaghurwe Alpha: When you say "shipment data" do you mean the order file generated from the requisition? or is the assumption is OpenLMIS has the shipment information and the driver/facility user is pulling up that information? Is this all on a phone app? |
2 | Batch and expiry manual validation check | If shipment data in OpenLMIS contains batch numbers and expiry dates (see shipment visibility feature), then at the point of delivery these batch numbers and expiry dates so that these can be verified by the facility as delivered and any discrepancies recorded.. | eLMIS | Must Have | |
3 | Match receipt data via smartphone | As a facility user/Driver, I want to log in and enter receipt information via a smartphone/tablet so that I can enter delivery data easily from different locations, or from the location where computer is not installed due to infrastructure challenges | eLMIS | Must have | Elaine Baker, Alfred Mchau, Alpha Nsaghurwe, Nsaghurwe Alpha: Which devices do the drivers use? Is the Ministry planning (or do they) provide drivers with devices so the target is one specific device? Can you elaborate on this requirement? Are you thinking SMS or an phone app? |
4 | Digitally sign delivery data | As a facility user/Driver, I want to digitally “sign” the delivery data so that I can confirm that the commodities delivery at my facility, and supervisors can use the data reported for decision making | eLMIS | Must have | This assumes per a previous story, the user has already logged in. |
5 | Delivery data export to ERP | As a facility user I want delivery data imported back into the MSD ERP so that the ERP does not have separate delivery verification procedures. | Tanzania ERP | Nice to have | |
Diagrams
Include any business process mapping, mockups, diagrams or visual designs relating to these requirements. Describes the tasks and the personas who perform those activities. The diagram provides the context for the user stories and serves as a focal point for achieving clarity and agreement among stakeholders. Looks like a standard flow chart.
There are three suggested models of how this could be done
Facility records delivery information into OpenLMIS using their own electronic device. Data then sent from OpenLMIS to ERP.
Facility signs in to OpenLMIS on driver’s electronic device, records delivery data into OpenLMIS. Data then sent from OpenLMIS to ERP. This may be a useful option where drivers have been given smartphones/tablets (as is the case in Tanzania), but the facilities do not have electronic devices suitable for logging in to OpenLMIS. It would be feasible to use a driver smartphone/tablet for this purpose because facilities do a full count and checking of the delivery while the driver is still on site.
Driver’s paper delivery logs entered into ERP when driver returns to MSD. Delivery data then sent from ERP to OpenLMIS. Note this would have long time lags for delivery data to be captured electronically and so is the least preferred option.
Dependencies
Description | Link |
---|---|
If the shipment functionality described was in use, the delivery feature could be made more usable. | Shipment File Import feature |
See also the “ILS Transport Module” system used in parts of Tanzania, and how its functionality could be incorporated into OpenLMIS itself. |
Open Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome | Status | |
---|---|---|---|
1 | By digitally “sign” the delivery data, is this just meaning the user who received it is logged with the receipt or is there an added layer of security? | ||
2 | Validate the terms used in user story #1. Should it be "shipment" instead of delivery and "order" instead of shipment"? | ||
3 | For Tanzania user stories: review the "so thats" added, review the label, and review the priority level. |
Out of Scope
OpenLMIS: the global initiative for powerful LMIS software