Broken approvals on OLMIS 3.2.1

Hello everyone,

   I'm reaching to you to start a discussion about ticket 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.
···

https://openlmis.atlassian.net/browse/OLMIS-3505

      Sebastian Brudziński

    Software Developer / Team Leader

sbrudzinski@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

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


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

···

On Tue, Dec 5, 2017 at 12:02 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hello everyone,

  I'm reaching to you to start a discussion about ticket [https://openlmis.atlassian.net/browse/OLMIS-3505](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


     sbrudzinski@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 openlmis-dev@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

     pgesek@soldevelo.com / +48 690 020 875

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

···


https://openlmis.atlassian.net/browse/OLMIS-3505

Sebastian Brudziński

Software Developer / Team Leader

sbrudzinski@soldevelo.com

Sebastian, thanks for raising this issue and advocating for the priorities for the Malawi implementation.

A few specific questions:

  • As Josh suggested, can you share the specific steps to reproduce (either commenting in OLMIS-3505 or opening a new specific ticket if you believe it is different)?

  • 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

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.
···

On 06.12.2017 05:38, brandon.bowersox-johnson wrote:

      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+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/3ff8058f-0d89-4e18-bd08-dd9f4a756d39%40googlegroups.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

On 05.12.2017 14:47, Josh Zamor wrote:

  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

On 05.12.2017 14:35, Paweł Gesek wrote:

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

                         pgesek@soldevelo.com
                          /                               +48 690 020 875
  **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

      SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

    Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

    Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
  On Tue, Dec 5, 2017 at 12:02 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com>
  wrote:

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

               sbrudzinski@soldevelo.com
        **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

            SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

          [                Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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 openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/e2c9b99a-653e-a9ae-348d-8b25a996b060%40soldevelo.com?utm_medium=email&utm_source=footer).

        For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Sebastian Brudziński

    Software Developer / Team Leader


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
sbrudzinski@soldevelo.com

Hello everyone,

   as promised, description in 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:

Do you have any additional thoughts? The problem I see is that stock management cannot handle well & recalculate the adjustments when events are not received chronologically. Should we aim towards making stock mgmt service always receive events in order (and perhaps validate that?) or should we rather somehow make stock mgmt able to recalculate adjustments when events come out of order?

Best regards,

Sebastian.
···

https://openlmis.atlassian.net/browse/OLMIS-3505
https://openlmis.atlassian.net/secure/attachment/36633/OLMIS3505-repro.jpg
On 06.12.2017 12:25, Sebastian Brudziński wrote:

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 Brudziński

    Software Developer / Team Leader


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
On 06.12.2017 05:38, brandon.bowersox-johnson wrote:

        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+unsubscribe@googlegroups.com.

    To post to this group, send email to openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/3ff8058f-0d89-4e18-bd08-dd9f4a756d39%40googlegroups.com?utm_medium=email&utm_source=footer).

    For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
    On 05.12.2017 14:47, Josh Zamor wrote:
    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

    On 05.12.2017 14:35, Paweł Gesek wrote:

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

                           pgesek@soldevelo.com
                            /                                 +48 690 020 875
    **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

        SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

      Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

      Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
    On Tue, Dec 5, 2017 at 12:02 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com>
    wrote:

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

                 sbrudzinski@soldevelo.com
          **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

              SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

            [                  Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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 openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/e2c9b99a-653e-a9ae-348d-8b25a996b060%40soldevelo.com?utm_medium=email&utm_source=footer).

          For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Sebastian Brudziński

                  Software Developer / Team Leader

sbrudzinski@soldevelo.comsbrudzinski@soldevelo.com

Hello everyone,

perhaps we could run this validation only if all the previous requisitions are approved?

Best regards,
Nikodem


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

···

On Fri, Dec 8, 2017 at 1:44 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hello everyone,

  as promised, description in [https://openlmis.atlassian.net/browse/OLMIS-3505](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

Do you have any additional thoughts? The problem I see is that stock management cannot handle well & recalculate the adjustments when events are not received chronologically. Should we aim towards making stock mgmt service always receive events in order (and perhaps validate that?) or should we rather somehow make stock mgmt able to recalculate adjustments when events come out of order?



Best regards,

Sebastian.



  On 06.12.2017 12:25, Sebastian Brudziński wrote:

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.
    On 06.12.2017 05:38, brandon.bowersox-johnson wrote:
        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+unsubscribe@googlegroups.com.

    To post to this group, send email to openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/3ff8058f-0d89-4e18-bd08-dd9f4a756d39%40googlegroups.com?utm_medium=email&utm_source=footer).

    For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
    On 05.12.2017 14:47, Josh Zamor wrote:
    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

    On 05.12.2017 14:35, Paweł Gesek wrote:

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
    **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

        SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

      [Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/98, 81-451, Gdynia, Poland

      Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
    On Tue, Dec 5, 2017 at 12:02 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com>
    wrote:

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

                 sbrudzinski@soldevelo.com
          **![](http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png)

              SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

            [                  Al. Zwycięstwa 96](https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96&entry=gmail&source=g)/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 openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/e2c9b99a-653e-a9ae-348d-8b25a996b060%40soldevelo.com?utm_medium=email&utm_source=footer).

          For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Sebastian Brudziński

                  Software Developer / Team Leader

       sbrudzinski@soldevelo.com


Sebastian Brudziński

    Software Developer / Team Leader


     sbrudzinski@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 openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/040e6102-7a9d-72bd-810f-d8cff2b1be15%40soldevelo.com.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

                            Paweł Gesek

                                                         Technical Project Manager

                           pgesek@soldevelo.com
                            /                                 +48 690 020 875

Hi Sebastian and everyone,

This bug has a root cause in Stock Management, where this same scenario causes an issue even if users are using Stock Management without Requisitions involved. My feeling is that we have screwed up the design of Stock Management and made reason validations too strict. Please review this new bug report for Stock Management that I marked as a cause of 3505:

https://openlmis.atlassian.net/browse/OLMIS-3808

To move towards a solution, I had good conversations with Josh and Mary Jo. Generally we are feeling that a 2-part solution would address this:

(1) Reason validations for physical inventory in Stock service be more flexible
– 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.

(2) Requisition service submits Physical Inventory to stock service at Authorized step (not waiting until final Approved step)

– doing it at Authorized step actually forces the data to come to Stock service in order by period most of the time, because Requisition service enforces this order, except for Emergency and for Rejections; note that (2) also has a big benefit of making the stock data visible on the stock card much sooner, since sometimes approvals can wait for weeks.

There are lots more details about (1) and (2) to figure out in order to propose this. I can spend another day and propose more of those details here on Dev Forum…IF people feel this solution is moving in the right direction. If not, please reply with questions or concerns.

-Brandon

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.
···

On 13.12.2017 06:09, brandon.bowersox-johnson wrote:

Hi Sebastian and everyone,

      This bug has a root cause in Stock Management, where this same scenario causes an issue even if users are using Stock Management without Requisitions involved. My feeling is that we have screwed up the design of Stock Management and made reason validations too strict. Please review this new bug report for Stock Management that I marked as a cause of 3505:
      To move towards a solution, I had good conversations with Josh and Mary Jo. Generally we are feeling that a 2-part solution would address this:
        (1) Reason validations for physical inventory in Stock service be more flexible 

          -- 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.
      (2) Requisition service submits Physical Inventory to stock service at Authorized step (not waiting until final Approved step)
      -- doing it at Authorized step actually forces the data to come to Stock service in order by period most of the time, because Requisition service enforces this order, except for Emergency and for Rejections; note that (2) also has a big benefit of making the stock data visible on the stock card much sooner, since sometimes approvals can wait for weeks.
      There are lots more details about (1) and (2) to figure out in order to propose this. I can spend another day and propose more of those details here on Dev Forum...IF people feel this solution is moving in the right direction. If not, please reply with questions or concerns.

-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+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@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](https://groups.google.com/d/msgid/openlmis-dev/14644df4-6749-47e0-9e33-35516037efe0%40googlegroups.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Sebastian Brudziński

    Software Developer / Team Leader


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
https://openlmis.atlassian.net/browse/OLMIS-3808
sbrudzinski@soldevelo.com

Hi Sebastian and team,

A draft proposed solution is now ready for your review and input:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/160137313/Stock+Management+options+for+3505+3808

This proposed solution is based on the ideas from Josh, Mary Jo, and input here from Sebastian. The wiki page linked above gives more details to #1 and #2 of this 2-part solution to OLMIS-3505/3808. I believe the proposed solution will solve the production issue and will make the product better and the data timeliness better.

Please respond here by Monday at Noon PST or use comments in the wiki page to share questions or feedback. This is scheduled for discussion and hopefully a final decision at the Product Committee this Tuesday, 19 December.

-Brandon