msupply-foundation / open-msupply

Open mSupply represents our most recent advancement in the Logistics Management Information System (LMIS), expanding on more than two decades of development inherited from the well-established legacy of the original mSupply.
https://msupply.foundation/open-msupply/
Other
23 stars 14 forks source link

Location merging #2453

Open Chris-Petty opened 1 year ago

Chris-Petty commented 1 year ago

Is your feature request related to a problem? Please describe 👀

Open mSupply needs to support location merging using a "link" table.

Describe the solution you'd like 🎁

Describe alternatives you've considered 💭

Moneyworks Jobcode 🧰

OMS:MERGE

Chris-Petty commented 1 year ago

@andreievg I want to start discussions on this one early because I know there are some outstanding complications with this feature and also supporting a clear cold chain for item lines. In hindsight after writing out this comment, I was more worried because I was thinking about the nastiness of being able to "consolidate" item lines in mSupply, which is a real mess for cold chain, location merge seems less treacherous.

First and foremost merges for locations are store data, so only executed on a remote site for active stores. So only really necessary if omSupply additionally has the UI to do location merging. We can defer the further decisions until it's a priority to support location merge functionality in UI? (Note, omSupply should never receive a "location" merge record via sync).

Second is the coldchain business. Legacy mSupply has this code:

            $obSensors:=ds.sensor.query("locationID IN :1"; New collection($t_location_to_keep; $t_location_to_delete))
            If ($obSensors.length>1)
                alert_display(17020; 290; "alert")  // "Locations cannot be merged as both of them have the sensors associated with it."
                $b_allok:=False
            End if 

I think we'd need the same validation check. I've double checked, it appears in mSupply sensors are soft deleted which makes sense. But, you can move sensors by changing their location, which in principal is fine but potentially not so good because we don't check any checks for breaches and temperature logs against either location... (early on I assumed "moving" would soft delete the sensor and make a duplicate sensor record in the location being moved to.)

Further, maybe it'd be appropriate to have a confirmation to the user to confirm that they want stock in the sensor-less location to effectively have the merged cold chain data added to their history?