Design supply partner model


We need to introduce the concept of a supply partner, one that handles some portion of the requisition approval and fulfillment workflow, for certain facilities and products.

There is some design work necessary here to map a supply partner to multiple programs, supervisory nodes, facilities and products.

A supply partner will have zero or more entries, each entry having a program, a supervisory node, and a list of facilities and a list of products.

Will need to figure out the "reference list" of facilities to be able to assign to this entry (facilities that support the program and is under the original supervisory node?)

Will need to figure out the "reference list" of products to be able to assign to this entry (FTAPs? but the facilities might be of different types, and there is currently no easy way to get a list of approved products by multiple facilities)

The product for a requisition can only be supplied by one partner. (It's the approach from eLMIS, do we want to keep it? Yes)

Acceptance Criteria

  • The output of this ticket should be a class diagram, RAML, and JSON schema.


Łukasz Lewczyński
October 16, 2018, 1:07 PM

the class diagram is available in the review.

Chongsun Ahn
October 15, 2018, 7:23 PM

Basically a UML diagram that shows the relationship between the different domain classes, their main properties, methods, etc.. So that we can show the design of this part of the domain.

Łukasz Lewczyński
October 15, 2018, 1:15 PM

Could you provide more details about the diagrams? I am not sure what information should be there. I mean I created a RAML and JSON schema for the model. I think domain classes would be very similar to DTO structure. Do we need anything more that should be present as class diagrams?


Nikodem Graczewski
September 28, 2018, 6:27 PM

I’m removing this one from the Sprint as we might not have the capacity to finish it.


Chongsun Ahn
September 5, 2018, 8:19 PM

We should keep the approach that eLMIS is taking here, a product can only be supplied by one supplier (whether main supplier or partner), since we have not heard of any requirement otherwise. In general, if we don't hear of a larger requirement, we should go with the simpler one.

We should output some class diagrams, and some RAML and JSON schemas.



Łukasz Lewczyński


Chongsun Ahn

Story Points


Time tracking


Time remaining





Fix versions