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?
I agree in that I think there’s a flaw in the thinking that led to the initial requirements of these valid sources and destinations. However I’m not sure what the right requirements are. The Product Committee would be the right place to surface the right requirements, to ensure this works how other locales would expect it to work, and I think the way to phrase that question is: How should an LMIS Administrator define which Locations (facility, organization, etc) any other Location may Receive from or Issue to?
Without better Requirements I’d be hesitant to accept what sounds like a work-around. Not opposed, only desiring for there to be an attempt to broaden the requirement’s gathering.
As a point of order, are you asking because this is what you’ve decided to do in Angola, or will you be able to wait for the next (not sure which one as we’re late to be changing 3.6) release?
Thank you, @joshzamor. I agree that running this kind of configuration request by the Product Committee would usually be quite reasonable. I’m under the perhaps-mistaken impression that one more developmental sprint exists prior to the Core’s upcoming release, though, and had hoped to potentially submit this work for it. Being able to would be quite beneficial. Angola hasn’t yet implemented it, and would be amenable to any reasonable option. As you picked up on, I don’t necessarily sell the suggested approach as an ideal one, but rather as a backward compatible and thus noncontroversial improvement.
Would it be reasonable to proceed with it if nobody responds with objections or alternate preferences on the Product Committee’s forum?
Just as a follow up, I’ll mention that I posted to the PC’s forum and presented the idea at their meeting today. Although nobody seemed to have strong concerns about the proposal, there was some interest in further considering it. Because such collaboration takes time, it’s unlikely we’ll still be able to create the functionality for the Core’s 3.6 release. Wes, though, seems open to the possibility of providing some kind of interim patch release prior to 3.7, though, so as to allow us to develop and contribute the feature with the PCs input even while including it in Angola’s October release as necessary.
@Ben_Leibert1 - I assume that you are actually referring to the 3.7 release (currently in progress) and the next release of v3.8, not 3.6 (which was released in May) and 3.7. As you noted in your Slack message to me, there is a little extra time in the 3.7 release window which does mean that we could include this type of release for version 3.7 and not have to worry about how to do an interim release between 3.7 and 3.8.
However, my main concern is similar to @joshzamor’s in that this feels like a work-around rather than a fully designed addition. My reason for this concern is the very specific way that this feature has been designed; it only seems to meet your specific needs, rather than more fully addressing the underlying issue. While the product committee has indicated that this type of feature would be a good addition, I think that we could use some more feedback from the tech committee on the planned technical implementation (as described here) before proceeding with any development.
Thank you very much @ibewes. You indeed intuited the releases I had in mind despite my having misreferred to them.
Although Angola would develop the upgrade and thus be its first beneficiary, it’s unlikely they’d be the last. Malawi doesn’t have a clear need for it right now, but their stakeholders see it as potentially beneficial. I don’t think it’s accidental that our first implementation with concrete plans to rollout stock-management countrywide is also the first to need this aspect of it tweaked.
My sense is that revolutionary change to sources/destinations would require much more thought, design, and general buy-in… but that nobody has need nor requirements for large changes right now. Folks on the PC and in Malawi/Angola thus seem to see the backward-compatible update as somewhere between innocuous and beneficial.
One suggestion from the Tech Committee has been to use geographic_level codes for the values of sharedGeoGranularity rather than direct level-numbers. We’d definitely adopt the advice. Does @joshzamor or anyone else on the Tech Committee have any other suggestions?
Putting the requirements process aside, the technical proposal sounds fine. I can think of an alternative that might be simpler if the facility type attribute isn’t going to be used? I assume that the contribution is also going to include an administrator mechanism to upload valid source and destination assignments as a CSV?
Thank you very much for your feedback. Although we’ve already added support for sources and destinations to the Config tool, we’ll certainly update it to support this tweak.