Broken approvals on OLMIS 3.2.1
Sebastian Brudziński
Hello everyone,
I'm reaching to you to start a discussion about ticket
https://openlmis.atlassian.net/browse/OLMIS-3505 that was found
during the RC period, but was not fixed for OpenLMIS 3.2.1. We
have recently started seeing a lot of occurrences of this problem
in Malawi, which in consequence blocks the facilities from
obtaining the final approval and issuing their order. I've
dedicated some time to investigate this a little bit, and I
believe we are having those issues due to having many approvals
happening "out of order", eg. approving September requisitions,
after October and November ones have already been approved &
released. The root cause of the issue and OLMIS-3505 is most
likely the fact that Stock on Hand is calculated in the order
determined by the "date of physical stock count", which defaults
to the last day of the period (if the manual date input is
disabled - like in Malawi). Finally, emergency requisitions can
also impact or cause this, as they are also happening kind of out
of order.
Our current workaround is to manually adjust the physical stock count date in stock management, which is of course far from being perfect and requires us to fix them one-by-one. Moreover, this extends the requisition processing time and the time of order issue, as each facility that is having this problem with approvals needs to wait for the dev team to "fix" the requisition first.
Therefore:
1. Would the core team be capable of fixing OLMIS-3505 AND releasing a patch for stock-management service? This is a top priority for Malawi, therefore we can offer any help or even provide the fix ourselves, as long as we can get it released.
2. If the above is not an option, do you see any other, viable
workaround? The current one, that I've described, is obviously a
short-term solution and doesn't fix anything.
I DO realize that a patch release would be quite problematic for
core at this point (some commits need to be reverted). At the same
time, the Malawi implementation cannot really go on for the next 3
or 4 months (next release) with broken approvals.
Please let me know if you have any additional questions or
something needs more clarification.
Thanks,
Sebastian.
Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
Paweł Gesek
Pawel
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/e2c9b99a-653e-a9ae-348d-8b25a996b060%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875
Josh Zamor
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
brandon.bowersox-johnson
Sebastian Brudziński
Hello everyone, thanks for the replies.
Brandon,
I don't think I've got any better repro steps at this point,
other than what's put in OLMIS-3505. I believe the issue we are
seeing in Malawi and the issue described in OLMIS-3505 are the
same, based on the returned error (there's only one
place/validation in the code where this specific message is
returned). The repro steps in OLMIS-3505 are quite tangled though,
I'm pretty sure we can find a cleaner way to reproduce this, with
minimal number of steps. We will work on that and either create a
new ticket or probably just add new details to OLMIS-3505.
On emergency requisitions in general - I think this is not really relevant whether the requisition is an emergency or a regular one. What's the essence here is how the physical stock count date is determined (and this differs between regular and emergency requisitions). You should be able to reproduce the issue without initiating emergency requisitions at all - we will attempt to have that reproduced, as mentioned above. I also believe there will be a single fix for regular and emergency requisitions.
Looking at the number of approvals not happening in order, I
don't think we would be able to enforce directly with the users
that all of them are approved in order, especially that we don't
have a full control over this. It would also require coordination
with both district supervisors and facilities when requisitions
are rejected.
Josh,
as mentioned, we will work on having better repro as a part of OLMIS-3505 or a new ticket.
On not holding a draft of facility physical inventory - it could help, depending on how we exactly design this. I'd be especially concerned with a scenario when a requisition is rejected and then re-submitted and re-authorized (reporting data can change, and we should support that). If done right and taking into consideration all edge cases, I believe this would resolve the root cause.
Pawel,
Yes, defaulting to the current date during the final approval
would most likely resolve this.
On re-calculating - I kind of thought that this is exactly what
happens now and is the reason we are seeing this problem. When
approvals are not done in order, stock management has got
incomplete / inaccurate data that can cause validations to fail -
or maybe I'm not exactly following what's the idea here.
Queueing the data and waiting for all previous requisitions to be
approved first sounds like an overcomplication to me, but is an
option that would also resolve the issue.
Finally, as mentioned above, with the number of approvals not happening in order, disabling out-of-order approvals would bring even more problems than we already have (also, what with requisitions that already are approved out-of-order?)
Thanks again!
Sebastian.
Sebastian, thanks for raising this issue and advocating for the priorities for the Malawi implementation.
A few specific questions:
- In 3505, Emergency requisitions are part of the Steps to Reproduce. In Malawi, does the bug only happen when Emergency Requisitions are part of the timeline, or do you have Steps to Reproduce where this bug is happening when only Regular requisitions are part of the scenario?- I ask because there are multiple other inter-related issues with Emergency Requisitions and there is a longer discussion happening as part of OLMIS-3587 about it. Do you think if we fix the issue for Regular requisitions that we can wait longer for the slower conversations about Emergency Requisitions?
- Do you have any feedback on Pawel's suggestions for quick fixes? Also, is there any way to prioritize the Malawi users approving requisitions in timeline order? (Like, can we tell them not to approve November if you still have September and October sitting there waiting for action.)
-Brandon
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/3ff8058f-0d89-4e18-bd08-dd9f4a756d39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
A quick question Sebastian before the wheels gather momentum. I remember this ticket well from triaging as the ticket that no one could reproduce. It now has what appears to be better steps to reproduce, however when you say that the root cause is likely, I’d like to ensure that the steps to reproduce the issue you’re concerned with, are exactly the steps in OLMIS-3505. If they’re not, then please file a new bug, and if it warrants it then link that the two bugs together. It’s critically important that the steps to reproduce are exactly the ones we need to follow to ensure the bug is fixed.
That’s my quick ask and the most important. My second thought is that this “out of order” issue could also be addressed by not holding a Requisition’s physical inventory in draft status until the final approval. If the Requisition’s physical inventory were in-fact completed and committed to stock management as an event before the Requisition “left the facility” (Submitted or Authorized status), then would that fix the root cause of this bug?
Once we’re solid on the steps to reproduce, we’ll discuss how we’ll move forward.
Best,Josh
Hello,What I am getting here, is that our current default flow is troublesome for implementations that do not use Stock Management, however are forced to deal with issues coming from Stock Management/Requisitions integration, strict Stock Management validations being the biggest issue. A few questions come to my mind:
1) Should this date default to the end of period given the order of approvals is not being respected? Would using the current date by default solve the issue? I understand that stock count date is different from the approval date, however implementations like Malawi don't care - perhaps there should be three options in program settings: show the date, hide the date and set to end of period, hide the date and set to approval date.
2) Should Stock Management be able to work backwards? Given that data is coming out of order to Stock Management, would it make sense for it to recalculate? I feel like making stock able to work with such data is the ideal solution here, but how much effort would this require? How complex will this get?
3) Should data going out to Stock Management get queued on the Requisitions side, and go out only once the chain of approved requisitions is complete. This would not require stock management to work backwards, and probably isn't that much effort, but we should be careful to not over-complicate this.
4) A nuclear option is to disable out of order approvals, but I don't think we want that. A different nuclear option is to allow implementations to disable Stock Management integration in requisitions. Should we consider these?
What does everyone else think?
Regards,
Pawel
Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
Hello everyone,
I'm reaching to you to start a discussion about ticket https://openlmis.atlassian.net/browse/OLMIS-3505 that was found during the RC period, but was not fixed for OpenLMIS 3.2.1. We have recently started seeing a lot of occurrences of this problem in Malawi, which in consequence blocks the facilities from obtaining the final approval and issuing their order. I've dedicated some time to investigate this a little bit, and I believe we are having those issues due to having many approvals happening "out of order", eg. approving September requisitions, after October and November ones have already been approved & released. The root cause of the issue and OLMIS-3505 is most likely the fact that Stock on Hand is calculated in the order determined by the "date of physical stock count", which defaults to the last day of the period (if the manual date input is disabled - like in Malawi). Finally, emergency requisitions can also impact or cause this, as they are also happening kind of out of order.
Our current workaround is to manually adjust the physical stock count date in stock management, which is of course far from being perfect and requires us to fix them one-by-one. Moreover, this extends the requisition processing time and the time of order issue, as each facility that is having this problem with approvals needs to wait for the dev team to "fix" the requisition first.
Therefore:
1. Would the core team be capable of fixing OLMIS-3505 AND releasing a patch for stock-management service? This is a top priority for Malawi, therefore we can offer any help or even provide the fix ourselves, as long as we can get it released.
2. If the above is not an option, do you see any other, viable workaround? The current one, that I've described, is obviously a short-term solution and doesn't fix anything.
I DO realize that a patch release would be quite problematic for core at this point (some commits need to be reverted). At the same time, the Malawi implementation cannot really go on for the next 3 or 4 months (next release) with broken approvals.
Please let me know if you have any additional questions or something needs more clarification.
Thanks,
Sebastian.
--
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/e2c9b99a-653e-a9ae-348d-8b25a996b060%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
Sebastian Brudziński
Hello everyone,
as promised, description in
https://openlmis.atlassian.net/browse/OLMIS-3505 has been updated.
I've added more generic steps to reproduce the issue, based on the
data from Malawi.
In simple terms - this will always occur and block approvals, if:
1. There's a negative adjustment in the stock management service
with the later date, than the one we are attempting to insert
(this date can be either manually chosen or generated, depending
on the program settings)
2. The stock on hand for the entry we are inserting is lower than
the negative balance from point 1.
I've also inserted a graphic directly in the ticket, that should
help visualize the problem & repro:
https://openlmis.atlassian.net/secure/attachment/36633/OLMIS3505-repro.jpg
Best regards,
Sebastian.
Nikodem Graczewski
perhaps we could run this validation only if all the previous requisitions are approved?
Best regards,
Nikodem
Hello everyone,
as promised, description in https://openlmis.atlassian.net/browse/OLMIS-3505 has been updated. I've added more generic steps to reproduce the issue, based on the data from Malawi.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/040e6102-7a9d-72bd-810f-d8cff2b1be15%40soldevelo.com.
brandon.bowersox-johnson
-- not to force users to always give reasons to account for the entire quantity difference counting from today's current-known SOH; by being more flexible we allow data to come into Stock out-of-order, which also helps offline/asynchronous situations.
Sebastian Brudziński
Hello Brandon,
I've reviewed the new ticket and have added the additional info
to explain where exactly the numbers from the error are coming
from.
I agree with (1). On (2) that sounds more like a business
requirement for the PC to validate (when should the data be
entered into the stock mgmt?). From my point of view, it would
make sense to do so after the authorize step, because we are
dealing with the product stocks reported by the facility and the
authorization step is the last one where you can still edit it.
Approvals deal with the ordering part of the requisition, so I
don't see a reason to keep the stock data as a draft, until
someone that is outside of the reporting facility, deals with the
approval. We would of course still need to consider what happens
when the requisition is rejected, since it goes through the
authorization again and so, the reported stocks can (in theory)
change.
Overall, this sounds good to me.
Best regards,
Sebastian.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/14644df4-6749-47e0-9e33-35516037efe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com