Different Approaches for store room managers to correct historical stock card line items.
There might be a case when store room manager created an incorrect stock card line item and he did not realize it after a certain period. When store room manager realized this incorrect line item, he would like to correct it. Thus, OpenLMIS should have a function to support store room manager correct any historical stock card line items.
Based on the architecture we use for the stock card feature, there are four different approaches to correct historical stock card line items:
- Replacement being scratching the old record off and creating a new one with correct information. I think this option is out for OpenLMIS if we want immutability to preserve full audit trail.
- Reversal being creating 2 new entries for each error, one to cancel the error out, another one to represent correct information.
- Difference within the past date, being creating a new entry that captures the difference between what was recorded and what should've been recorded.
- Difference within the current date being creating a new entry that captures the difference between what was recorded and what should've been recorded.
Let us use an example to explain different approaches. Below is a stock card sample:
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 10 | Ward 1 |
|
| 40 |
13 Jan |
|
|
|
| 10 | Expired | 30 |
|
|
|
|
|
|
|
|
Today is 26th Jan, the store room manager realized that the line item happened on 12th Jan (mark in red) was wrong, he actually issued 20 instead of 10.
Replacement, the old line item happened on 12th Jan will be replaced by a new line item inputed by end user and the old line item will be deleted from the system. After user's correction, the stock card will be like this:
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 20 | Ward 1 |
|
| 30 |
13 Jan |
|
|
|
| 10 | Expired | 20 |
|
|
|
|
|
|
|
|
- Reversal, the old line item happened on 12th Jan will not be changed instead store room manager needs to create two more line items. One to cancel the old line item while the other one to record the correct line item.
Option A
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 10 | Ward 1 |
|
| 40 |
12 Jan | 10 | Ward 1 |
|
|
| Data Correction | 50 |
12 Jan |
|
| 20 | Ward 1 |
|
| 30 |
13 Jan |
|
|
|
| 10 | Expired | 20 |
Option B
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 10 | Ward 1 |
|
| 40 |
12 Jan |
|
|
|
| +10 | Data Correction | 50 |
12 Jan |
|
| 20 | Ward 1 |
|
| 30 |
13 Jan |
|
|
|
| 10 | Expired | 20 |
Option C
Shiyu Jin (Deactivated) I didn't have time to make screen shots for the selecting of the transaction to correct. If you have time it would be great.
- the user indicates they want to do a correction on a specific transaction/stock card lineitem (either through a reversal/data correction screen or view soh screen by selecting "data correction: or something...)
- user selects the specific stock event (12 Jan Issue to Ward 1 of 10)
- enters the correct information (12 Jan Issue to Ward 1 of 20), if you want to make a new stock line item
- the following is captured in the system and could be a retrieved by auditors, but it is not what the end user would view
Date | Description | Debit | Credit | Balance |
---|
10 Jan | Receive from Facility 1 |
| 50 | 50 |
12 Jan | Issue to Ward 1 | 10 |
| 40 |
12 Jan | Data correction (reversal) |
| 10 | 50 |
12 Jan | Correct Issue to Ward 1 | 20 |
| 30 |
13 Jan | Expired | 10 |
| 20 |
- the storeroom manger would view the following. Potentially we could have it where you could click on the corrected transaction to see the history but I think the main point is that the system will display the corrected action and the system will do the reversal in the backend.
Horizontal View
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 20 | Ward 1 |
|
| 30 |
13 Jan |
|
|
|
| 10 | Expired | 20 |
Or a Vertical View
Date | Description | Source/Destination | Quantity | Stock on Hand |
---|
10 Jan | Receive | Facility 1 | 50 | 50 |
12 Jan | Issue | Ward 1 | 20 | 30 |
13 Jan | Expired |
| 10 | 20 |
- If user wants to delete a historical stock line item then:
- User's view on the stock card after deletion of the wrong stock line item
- Audit's view on the stock card after deletion of the wrong stock line item
- Difference within the past date, old line item remains the same but store room manager will create a new line item for that past date but its quantity is only be the difference between the wrong line item and the correct line item.
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 10 | Ward 1 |
|
| 40 |
12 Jan |
|
| 10 | Ward 1 |
|
| 30 |
13 Jan |
|
|
|
| 10 | Expired | 20 |
- Difference within the current date, old line item remains the same but store room manager will create a new line item within the current date but its quantity is only be the difference between the wrong line item and the correct line item.
Date | Receive Quantity | Receive From | Issue Quantity | Issue to | Adjustment Quantity | Adjustment Reason | Stock on hand |
---|
10 Jan | 50 | Facility 1 |
|
|
|
| 50 |
12 Jan |
|
| 10 | Ward 1 |
|
| 40 |
13 Jan |
|
|
|
| 10 | Expired | 30 |
25 Jan |
|
| 10 | Ward 1 |
|
| 20 |
Each approach has its cons and pros:
| Pros | Cons | Comment |
---|
Replacement | - Usability, it the easiest way for user
- It might be the current process on paper form
| - No traceability because wrong data will be deleted
- Data integrity, system never knows when the data is correct
- System performance issue, system needs to recalculate all the stock line item in order to update the stock on hand whenever there is a correction
- Impact other stakeholders' usability by receiving 'unwanted' notifications, OpenLMIS will send a notification to other users whenever the stock on hand amount changes.
|
|
Reversal | - Traceability, it records all the line items
- Reflect the reality, the correct event is created and recorded
| - Confusion about how to make the cancel line item especially for the issue to/receive from fields. where I receive from does not necessarily reflect where should be issued to.
- System performance issue, system needs to recalculate all the stock line item in order to update the stock on hand whenever there is a correction
- Impact other stakeholders' usability by receiving 'unwanted' notifications, OpenLMIS will send a notification to other users whenever the stock on hand amount changes.
|
|
Difference with past date | - Traceability, it records all the line items
- Usability, it only needs to create one stock card line item
| - Confusion about how to make the 'difference' line item especially for the issue to/receive from fields. where I receive from does not necessarily reflect where should be issued to.
- System performance issue, system needs to recalculate all the stock line item in order to update the stock on hand whenever there is a correction
- Impact other stakeholders' usability by receiving 'unwanted' notifications, OpenLMIS will send a notification to other users whenever the stock on hand amount changes.
- Facts are not recorded. According to above example, the fact is issuing 20 to ward 1 but what recorded on the stock card would be two line items: issue 10 to ward 1 and issue 10 to ward 1. Neither of these two stock line items actually happened.
|
|
Difference with current date | - Usability, it only needs to create one stock card line item and it will not send 'unwanted' notifications
- Data integrity, because historical data will not be changed
- Traceability, it records all the line items
- System performance because it does not need to calculate all the past line items
| - Confusion about how to make the 'difference' line item especially for the issue to/receive from fields. where I receive from does not necessarily reflect where should be issued to.
- Facts are not recorded. According to above example, the fact is issuing 20 to ward 1 but what recorded on the stock card would be two line items: issue 10 to ward 1 and issue 10 to ward 1. Neither of these two stock line items actually happened.
- Stock on hand report will be impacted by the wrong line item.
|
|