as a part of the updating products epic, I’m currently looking into the approach to version (or not) the FacilityTypeApprovedProducts. There are two main questions that need to be answered:
- Should FTAPs be versioned themselves?
- Should FTAPs reference specific versions of orderable?
Before diving into those questions, a quick recap on the FTAPs:
Facility Type Approved Products allow you to segment orderables by facility type. Although a program supports a specific list of orderables, different facilities may not have the capacity to support providing the orderables. This is why you would want to segment orderables by facility type. Each facility that performs duties related to the requisition process must be set up with their Facility Type Approved Products.
How does that look in practice? FTAPs are taken into consideration in two of our services: requisition and stock management.
Requisitions rely on the two things in FTAPs: first of all - their presence. A newly initiated requisition will only be populated with the products that are supported for the given program and at the associated facility type. In other words, an FTAP entry must exist in the database for the combination of an orderable-facility type-program in order for that product to appear in requisitions. If there’s no such entry, the product won’t appear in the requisitions. If the FTAP entry was there at some point but was removed later on, all the past requisitions will properly display and link to that product, but no new requisitions will have that product included anymore. The second thing that requisitions need from FTAPs is the max periods of stock property that OpenLMIS allows to set for each orderable-facility type-program combo separately. This property helps calculate the reorder quantities for the product in requisitions.
Things get a little more blurry with the Stock management service. FTAPs help determine which products we can manage at any given facility. If there’s an FTAP entry for the given orderable-facility type-program combo, we will be able to manage the given product at the facility - include it in the physical inventory, receive from another facility, issue to other facilities and view its stock on hand. If the entry is removed, we lose access to the related stock card - we can no longer receive or issue that product, or even view its historical transactions. The Stock Management service only relies on the presence of the FTAP entry. Whether the current behavior is expected is unclear to me at the moment. It seems weird that we even lose read-only access to the stock card - on the other hand, if we wanted to ensure the access to the historical transactions, we would need to somehow mark that this product is no longer managed for this facility.
Now, how does this impact our questions? Should we version FTAPs? In my opinion - no. With FTAPs we are mainly interested in “here and now”. If an entry for FTAP exists, we include it in new requisitions or allow stock transactions. This fact of “presence” of the FTAP entry is directly captured in created requisitions and stock cards. If the requisition contains a given product it means that an FTAP entry existed. Same with stock cards - if it exists, it means that the FTAP for the product existed at some point. The only property we are interested in capturing is the max periods of stock value in requisitions and we would like to keep it as it was at the time of requisition initiate. It seems though that introducing versioning just for this single property doesn’t make much sense. Especially, that if we resigned from snapshotting it in requisition, we would need to make an additional call for each product to retrieve its value in requisitions.
How about having FTAPs reference a specific version of the orderable? In other words, if I update my orderable (e.g. by changing its price, or pack size) do I automatically want to cancel the existing support for this product in requisitions and stock management? Based on the observations of product updates in Malawi, that doesn’t seem to be the case. All product updates are separate from their support at the facilities and programs. Based on the first question, it also doesn’t look like we need to keep track of which orderable versions were supported by FTAP. Clients of the FTAP endpoint are not interested in this - they only need to know whether the product is supported right now.
Summarizing all of the above, the path forward that I see is:
- Do not introduce versioning of FTAPs
- Drop the reference to orderable by its version and restore the relation that we originally had - by orderable id
If you have made it through that post - congrats! Now let me know what are your thoughts This is a complex topic, so any feedback is welcome before we go into the action with the implementation work.