openlmis-ref-distro

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OLMIS-6351: Dropped reference to orderable version from FTAP
OLMIS-6351: Dropped reference to orderable version from FTAP
Are there other location types that we may need to consider? If so, would we want this description to be more general?

Are there other location types that we may need to consider? If so, would we want this description to be more general?

Geographic

Geographic

Is it likely that an ERP system might be the source of truth for this kind of data, rather than OLMIS? I am thinking of a country that wants to use OpenLMIS primarily for the requisition process bu...

Is it likely that an ERP system might be the source of truth for this kind of data, rather than OLMIS? I am thinking of a country that wants to use OpenLMIS primarily for the requisition process but leverage an existing ERP system for inventory-related processes.

Would OpenLMIS be the source of truth for cce or would a monitoring system like NexLeaf?

Would OpenLMIS be the source of truth for cce or would a monitoring system like NexLeaf?

Is bearer tokens the only method that we want to support?

Is bearer tokens the only method that we want to support?

Also, if you add something about smart endpoints/dump pipes, including some detail about what that means in practice would be helpful as well.

Also, if you add something about smart endpoints/dump pipes, including some detail about what that means in practice would be helpful as well.

I would prefer to lowercase device, so it doesn't get confused with FHIR's Device.

I would prefer to lowercase device, so it doesn't get confused with FHIR's Device.

a part

a part

comes from

comes from

Datetimes

Datetimes

Would you be able to add something in here about smart endpoints and dumb pipes? I think it would be helpful.

Would you be able to add something in here about smart endpoints and dumb pipes? I think it would be helpful.

OLMIS-5584, change toc depth to 2
OLMIS-5584, change toc depth to 2
Looks good, thanks!

Looks good, thanks!

Agreed, thanks.

Agreed, thanks.

I agree that introducing enum values now is too dangerous. I would say we could create a separate ticket to implement the flag into stock event structure and start working on it after 3.6 release.

I agree that introducing enum values now is too dangerous. I would say we could create a separate ticket to implement the flag into stock event structure and start working on it after 3.6 release.

Could we add information about those variables into README files (the Environment variables section) in services that use them?

Could we add information about those variables into README files (the Environment variables section) in services that use them?

Thanks Josh Zamor I appreciate the feedbacks.

Thanks Josh Zamor I appreciate the feedbacks.

Yes, these are coming from the env variable and I have also added those to the ref-distro too. The commit is added to this review.

Yes, these are coming from the env variable and I have also added those to the ref-distro too. The commit is added to this review.

Enum would be great. Are you thinking of something like "StockEventType" that would be an attribute of the StockEventDto? In general, My observation with the current design is that Stock Event typ...

Enum would be great. Are you thinking of something like "StockEventType" that would be an attribute of the StockEventDto?

In general, My observation with the current design is that Stock Event types are identified by guessing. If any line item has destination or source, then it must be transfer. If none of the line items have reason, then it must be physical inventory. Or something in those lines. I don't think this much guessing scales as more event types are introduced.

I think Introducing Stock Event Type as an Enum would be a significant breaking change that will potentially affect clients as well. My reason for going with another guess work (if there is one unpack reason, then it must be a kit unpacking event) for Kit Unpacking was to avoid that breaking change.

Since we are too close to the release 3.6, I do not think it would be ideal to break so much. One other thing that can be done for the short term and as a step towards using the Enum properly can be to introduce the Enum but initialize it using the existing guess methods when the processing context is set. Would that be okay?

It checks if the quantity supplied by the client for the constituents accounts for what was specified in the unpack list. Example: Assume the unpack list for Kit A says, A contains, 10 Bs and 12 C...

It checks if the quantity supplied by the client for the constituents accounts for what was specified in the unpack list.

Example: Assume the unpack list for Kit A says, A contains, 10 Bs and 12 Cs. Assume 2 As were unpacked. This method checks if there are two or more line items that account for 20 Bs and 24 Cs. If there are line items for 20Bs and 20Cs, it would throw an error because the 4Cs are not accounted for.

I will rename the method.

Left a couple comments. Thanks Elias.

Left a couple comments. Thanks Elias.

With isPhysicalInventory() as well I wonder if it's time for an enum?

With isPhysicalInventory() as well I wonder if it's time for an enum?