2019-12-17 Volume and Temperature Support
Participants
@Josh Zamor
@Chongsun Ahn (Unlicensed)
@Ben Leibert
@Aleksandra Ciesińska
@Mateusz Kwiatkowski
Initial Notes
Tickets for reference:
According to Josh’s comment in SELV3-13, we can add all required fields for Orderables can be added to the core model with the requirement that they should be implemented according to GD1 standard. We need to support different measurement units for those fields which would require introducing additional fields for temperature and volume fields, for both those would be (based on http://apps.gs1.org/GDD/bms/GDSN_31/Pages/bdtList.aspx?semanticURN=urn:gs1:gdd:bdt:Measurement):
measurementUnitCode - code of unit (i.e. C and F for temperature)
codeListVersion - list of supported units
I’m not sure how to best approach adding those to the model, but I would propose adding a new class (i.e. MeasurementUnit) with those 2 fields mentioned above and adding following fields to Orderable class:
minimumToleranceTemperature [Integer]
maximumToleranceTemperature [Integer]
inBoxCubeDimension [decimal]
temparatureMeasurementUnit [MeasurementUnit]
volumeMeasurementUnit [MeasurementUnit]
All of the above fields could be optional.
For the SELV project we would need to filter Orderables to get only those used by CCE. I’m not sure if we could use those temperature/volume fields to determine it (i.e. inBoxCubeDimension should be filled to be considered a CCE orderable) or we would need another field which could be boolean to simplify filtering + enabling non-CCE products to use inBoxCubeDimension field if needed.
From the user’s point of view, I’m not sure about which data is accurate in terms of current volume that is occupied by CCE products - either beginning balance from the previous requisition or current/end of the period stock summary. If the first then we probably could use requisition and orderable data that is cached on the UI. For stock-based requisitions that would be an end-of-period stock summary, for regular requisitions beginning balance would be taken from previously reported requisition. This could be invalid because we won’t have this value for emergency requisitions. For the second option, we could get current stock on hand values for CCE-orderables.
If we won’t be able to add changes to referencedata service and use extradata field to store those values then we won’t be able to filter those while fetching them from referencedata. If we are going to use cached orderables from requisition then we could filter them on the UI by CCE properties from extradata and get stock info only for those. I can see an issue with this approach - if requisitions will have fewer orderables than stockmanagement service then we would need to get info from there and fetch more orderables from referencedata service.
Calculating the available volume could be either done on the SELV dedicated UI or on the additional endpoint that could be introduced to the new SELV equipment service. This endpoint could take facilityId value and return a summary that would contain available volume - that way all data would be retrieved on the backend side which is considerably faster than on the UI.
Josh has mentioned FHIR service as a possible solution for retrieving the data. Malawi is submitting measure reports based on requisitions to FHIR service using nifi. We could do a similar thing - using nifi to publish measures based on stock data and then probably fetch needed info on the requisition screen.
Additional Notes
New Properties
So as to bolster cross-system interoperability, we need to follow GDD naming conventions when adding new properties to our domain model. That’s the minimum we need to do in order to add min/max temperature values to Orderables and/or TradeItems.
In GDD, the datatype of minimumToleranceTemperature contains a numeric primitive as well as a unit of measure (UoM) which is like an emum (“CodeList”) of allowable values (eg: Fahrenheit, Celsius, etc).
We should be explicit about which UoM we’re using. This may be through convention and documentation of our API. It may be through properties within the responses served by our API.
A robust implementation would allow clients to specify both a value and a UoM. Internally, OpenLMIS would then convert between various units of measure (eg: Celsius to Fahrenheit) whenever necessary.
Alternatively, though, we could require values to be specified in eg: Fahrenheit and return an error if they aren’t. This would suffice for now.
We should use minimumToleranceTemperature rather than minimumTemperature.
An Orderable can be either a:
TradeItem Type Orderable - An Orderable backed by a TradeItem (ie: with a specific manufacturer)
Commodity Type Orderable - An Orderable which isn’t backed by a TradeItem
Our new properties (like minimumToleranceTemperature) should technically be associated within TradeItem Type Orderables. In that case, we have a specific manufacturer of a tangible item specifying that their product has a minTemp of X.
Nevertheless, it would be alright to instead associate our new properties with Commodity Type Orderables. In that case, something like minTemp would be a reference value. A “reference value” is essentially an “approximate value.” For instance, when buying multiple instances of product X from various vendors, each vendor may have a different price. It’s still useful to be able to say that product X generally costs a certain amount, though, and this single value is its reference price. The reference price is informative rather than definitive. So to, TradeItem Type Orderables have specific minimumToleranceTemperature values, whereas Commodity Type Orderables have reference minimumToleranceTemperature values.
The minimumToleranceTemperature property should have that name regardless of whether we add it to a TradeItem Type Orderable or a Commodity Type Orderable, and regardless of whether or not it’s thus a reference-value. Users simply have to understand from context (rather than based on the property name) whether or not it’s a reference value.
As mentioned, our new properties (like minimumToleranceTemperature) should technically be associated within TradeItem Type Orderables. It’s common, though, for TradeItem properties to instead be defined within Orderable. It would be fine to define our properties within Orderable.
PCMT
PCMT v1 will be done on or prior to January 20th.
The 3.9 version of OpenLMIS, slated for release sometime in March, will then include integration with it. The longterm vision for OpenLMIS is that it rely on rather than merely support PCMT for product management. Therefore, for SELV, we shouldn’t necessarily invest time in updating existing product screens to support new properties that we add. Instead, it may be better to invest the time into PCMT (wherein users would have access to the new properties).
We can play with any of these PCMT servers:
http://demo.akeneo.com
http://test.pcmt.villagereach.org - Work in progress so Jenky
http://showcase.pcmt.villagereach.org
Username and password for each server: admin/admin
We can do whatever we'd like to these servers - they automatically reset themselves on a set schedule.
Also check out https://gitlab.com/pcmt/pcmt/-/wikis/home.
Services
The stock-management service should contain the endpoint which returns the total volume of all inventory and/or all inventory which requires CCE.
The CCE service should probably be where we’d have an endpoint which returns the total available CCE volume at any given facility.
Because we won’t be sending any of our new properties/values to ColdTrace, we shouldn’t have to update our FHIR endpoints.
The Core team plans on quarterly OpenLMIS releases. We can coordinate the release of individual services with them, however, at any time.
Identifying Products Reliant on CCE
We probably shouldn’t presume that existence of a non-null maxToleranceTemperature means that an Orderable needs cold-chain.