You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
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.
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 |
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 |
- 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.
|
|