Requisition statuses in fulfillment

Technical Committee
#1

Hello everyone,

while looking at the statuses in our requisitions and filling the testing gap for them, I fixed https://openlmis.atlassian.net/browse/OLMIS-2795 . The problem was that the fulfillment service mirrors the statuses from requisitions in this enum (https://github.com/OpenLMIS/openlmis-fulfillment/blob/master/src/main/java/org/openlmis/fulfillment/domain/ExternalStatus.java) which was not updated when Malawi introduced the REJECTED status.

I fixed this for now by simply adding the status, but isn’t this the kind of tight coupling between services we want to avoid? Fulfillment services use the list of status changes from requisitions primarily to generate the order pdf with information such as authorizer, date authorized etc.

A fairly simple way to improve this would be to change this field to a string in the fulfillment service and ignore unrecognized status changes, this wouldn’t require API changes and would drop this dependency. The other method would require changing the API to not expect a status change dump from requisitions, only the info we need (perhaps we want to keep storing all the status change history with an order as well?).

Do you think we should get rid of this dependency? If yes, with which approach?

Regards,

Paweł

···

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875
#2

Hi Pawel,

Thanks for catching this, and you raise a really good point: this is coupling from Fulfillment to Requisition services of the variety that we do not want. From my perspective I posted about a similar undesired behavior here:
https://groups.google.com/d/msg/openlmis-dev/vGdO7yaxpUg/XzLOexrJAQAJ

When I’m looking at the Fulfillment service, I don’t see any reason for it to have Requisition status changes, except perhaps for a single report - the view order report accessed through the View Orders screen. Perhaps requirements changed here, and that’s why we ended up giving the requisition statuses when we create an order, however it goes against a desire we’ve had for the fulfillment service: to support requisition-less orders.

The next steps as I see them:

The first bullet points are in progress and have tickets. The last three (okay 2) will need tickets and to be prioritized.

-Josh

···

Paweł Gesek

Technical Project Manager

pgesek@soldevelo.com / +48 690 020 875