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.