search

clintonhealthaccess / chailmis-android

Android Tablet Application for Logistics Management in the DHIS2 Platform
Other
7 stars 6 forks source link

Client sends data in absolute numbers #253

Open ihassin opened 8 years ago

ihassin commented 8 years ago

Scenario: Updating with absolute numbers

Given the server and client have "5" items of type "A" When I update SOH with "Received" "A" "10" And the sync succeeds Then the client updates SOH for "A" with value "15" And the server shows that there are "15" items of type "A" for my clinic

This "SOH Received 15" represents the final, absolute number for item "A". It may represent a single physical transaction of adding 10 at once, or the result of the operator adding 20 and dispensing 10 prior to syncing.

Another example: Scenario: Chaining with absolute numbers Given the server and client have "5" items of type "A" When I update SOH with "Received" "A" "10" And I update SOH with "Dispensed" "A" "5" And the sync succeeds Then the client updates SOH for "A" with value "10" And the server shows that there are "10" items of type "A" for my clinic

LakshmiCHAI commented 8 years ago

The calculation of SOH should not happen on the server side, but rather on the client side. So in the case of the first scenario, both client and server start with SOH = 5. Client received 10 => Client SOH = 15. Sync initiated SOH value 15 is sent to the server Sync successful Server updates SOH = 15.

The received value of 10 is also sent to the server for that data element, but server does not use it to calculate SOH.

The chaining with absolute numbers (scenario 2) is correct in that if several dispense or receipt activities have taken place before the set sync time, when syncing to the server, the app will sync a cumulative of all the dispense or receipts. However, again, the actual value of SOH calculated on the client will sync to the server; the server will not calculate SOH based on the activities.

karloskalcium commented 8 years ago

@LakshmiCHAI : Given that, what does the server do with the "received" / "dispensed" values? What happens if there is a discrepancy - e.g. stock + received - dispensed <> SOH provided to the server - is that just to be ignored?

LakshmiCHAI commented 8 years ago

@karlwbrown the values are used for reports and analysis (e.g. we may want to look at consumption/dispensation trends, expiration volumes, etc.). yup, we'll have to ignore any discrepancy - it's better than a discrepancy between client SOH and server SOH essentially, which is what we're addressing now.

ihassin commented 8 years ago

@LakshmiCHAI:

The calculation of SOH should not happen on the server side, but rather on the client side.

Can you please explain this logic? It's counter-intuitive and I refer to this in #256.

ihassin commented 8 years ago

@all : in the meantime, Bin will make sure that both SOH and transactions are being handled correctly on the client side when it emits its information to the server. It's my understanding that the API can accept both formats of data, so my questions regarding client-side calculations do not need to block development.

chai-lmis commented 8 years ago

@ Itamar, please confirm what the 2 forms of data are Egwuma

garymabin commented 8 years ago

I think Itamar regard that the SOH and the other commodity actions are separate data, actually they are the same type, the app just synced the other commodity actions' data set value (like receiving, dispensing, adjustment) previously, And I calculated the SOH and synced it in a separate call recently , but SOH is actually treated as just one commodity action in the app.

LakshmiCHAI commented 8 years ago

@ihassin By calculation of SOH I mean "new SOH = old SOH + received - dispensed - losses - adjustments". This calculation is happening at the client side AND server side right now. i.e. commodity action (received, dispensed, etc.) values are synced with the server and the server then calculates the value of the new SOH based on the action values. SOH value is currently not sent from client to server. We want to switch to syncing the value of SOH directly from the client to the server.

Not sure how this relates to #256. The latest value of SOH should be retrieved from the server - doesn't matter if the actual calculation of the value is done on the server side.

Let me know if this is clear - happy to have a quick chat if needed.

ihassin commented 8 years ago

@LakshmiCHAI Got it. @garymabin has implemented this and is currently testing.

ihassin commented 8 years ago

Due to poor connectivity with the QA server we will use a mock service using test class DHIS2Test. I will be in contact with @egwuma to try to help resolve QA service connectivity.

garymabin commented 8 years ago

I've finish the SOH sync code and reduce the sync frequency to 4 times a day and add some unit test. see #11882f

ihassin commented 8 years ago

Excellent!

On Oct 10, 2015, at 06:22, Bin Ma notifications@github.com wrote:

I've finish the SOH sync code and reduce the sync frequency to 4 times a day and add some unit test. see #11882f

— Reply to this email directly or view it on GitHub https://github.com/clintonhealthaccess/chailmis-android/issues/253#issuecomment-147071644.

chai-lmis commented 8 years ago

Tested Ok: same problem with card 252, Stock Balance on the top of the bin card (near the min/max values) does not update with the new SOH value

chai-lmis commented 8 years ago

explained on card 255

ihassin commented 8 years ago

This is the top priority for now. Please do this before #254

chai-lmis commented 8 years ago

i have updated to the latest QA version 1,8.552, and so far there has been no sync from the app to the server. I dispensed stock and checked the server after analytics and scripts ran successfully, and there was no values for stock dispensed and SOH on the server

garymabin commented 8 years ago

@Egwuma, Do you trigger the sync manually?

chai-lmis commented 8 years ago

yes this happened in both cases, triggered manually and auto sync

chai-lmis commented 8 years ago

@Bin, any update on this?

garymabin commented 8 years ago

@chai-lmis, I check the code between the last two QA versions, there aren't any code changes about SOH sync except for reducing syncing frequency and fixing unit test, so it is weird that the SOH sync dose not works in the latest version but works in previous versions.

garymabin commented 8 years ago

@chai-lmis, Would you mind to test it again? Cause I can not see any difference between in the 2 versions really.

ihassin commented 8 years ago

@egwuma - it seems the app side is ok as it's not giving any errors when syncing. I need a way to debug on the server side. Either direct access to its logs, or work with one of the devs on the server side to see transactions moving.

ihassin commented 8 years ago

We still don't have a way to ssh into the server to see logs in real time. @bin and I will discuss this during tonight's meeting to see if there's another way to debug. If not, we'll pass it on to the server-side team to debug.

garymabin commented 8 years ago

@all, I think we have finished all the sync stuff, please have a check.