Specification of Stock Sources and Destinations

Hi everyone,

The stock management service currently lets implementers specify the source and destinations from and to which stock may respectively be received and issued. Each source/destination can be a facility or generic string, referred to as “organization,” and each can be associated with a facility type and program to which they’re relevant.

For example, to specify the set of valid sources, an implementor might upload a ValidSources.csv file comprised of something like:

Although this works, it doesn’t allow for a convenient way of limiting sources/destinations by geographic zone. Angola needs the option of limiting interfacility stock transfers to facilities which both reside in the same region. Because this seems like a potentially common need, I’d like to solicit ideas for how to address it and suggest a potential approach.

As mentioned, the configuration to specify a valid source currently looks like:

programCode, facilityTypeCode, source

We could potentially add a fourth, optional, parameter as follows:

programCode, facilityTypeCode, sharedGeoGranularity, source

The optional sharedGeoGranularity value could correspond to a geographic level number and allow for the following behavior:

  • A value of X which corresponds to a geographic level would indicate the level within which facilities must both reside in order to be considered valid source/destinations for stock transfer between the two. For example, if the geographic level of an entire country were 1, then a sharedGeoGranularity value of 1 in the following piece of configuration would pose no particular restriction:

programCode, facilityTypeCode, 1, sourceX

If, on the other hand, a geographic level of 3 were to refer to “district,” then the following snippet would only allow sourceX to serve as a source of stock for facilities of type facilityTypeCode which reside in the same district as does sourceX:

programCode, facilityTypeCode, 3, sourceX

  • Specifying no value for sharedGeoGranularity would result in no geographic filtering, and therefore behavior no different from what the system currently exhibits.

As an aside, sourceX can currently refer to a string/organization rather than facility. In this case, because organizations aren’t associated with geographic zones, the notion of restricting them by zones is inapplicable. The proposed sharedGeoGranularity option would accordingly have no effect on strings/organizations.

The appeal of this approach is that it’s backward compatible yet adds useful functionality. Do you think it would be helpful? Is there an alternate approach that you think we should consider?

Kind regards,
Ben