The Angola project will soon have the need to use the valid_source_assignments and valid_destination_assignments within stockmanagement, but to limit the options to transfers which occur within the same geoZone.
It seems that achieving this would currently require an awkward use of faciltyType. Specifically, we could break facilityTypeX into facilityTypeX-GeoZone1, facilityTypeX-GeoZone2, facilityType-GeoZoneN and then use these highly specific facilityType values within the valid_source_assignments and valid_destination_assignments configuration. This would require a departure from the historic semantics of “facility type,” however, along with a lot of additional setup/configuration overhead.
A better approach may be to amend the options available within the valid_source_assignments and valid_destination_assignments configuration. They’re currently comprised of these three values:
programCode, facilityTypeCode, destination
What do folks think about adding a fourth as follows:
programCode, facilityTypeCode, sharedGeoGranularity, destination
The new sharedGeoGranularity would correspond to a levelnumber in referencedata.geographic_levels. A null value would cause the system to work as-is. Otherwise, a value of X would dictate the geoLevel precision at which facilityTypeCode-destination facility pairs must match the destination. In Angola’s case, a value of 1 would represent the entire county (as specified in referencedata.geographic_levels) and thus permit all facilities matched by programCode-facilityTypeCode to be associated with the specified destination. A value of 2 would require that the aforementioned facilities share the same province as the destination, while a value of 3 would require that they share the same municipality.
Whenever the destination is an Organization rather than facility, any specified geoLevelAssociation would be ignored.
It seems this approach would slightly complicate the definitions of Angola’s ValidSources.csv and ValidDestinations.csv files, but make them more flexible and much easier to maintain. Does this seem like a reasonable approach which the Core project would be amenable to incorporating?