The StockTakeUnit1ID failsafe code is becoming an issue

I have had this discussion with a few people, but we need to formalize this.

There is a process that we run after the VendorItem and VendorEntityItem imports called UpdateEntityItemUnitsFromVendor which attempts to set any missing ReportingUnit and StockTakeUnit1 data on the tbEntityItem table based on the "largest" UOM from the VendorEntityItem data available.

The problem is that we are up to 450,000+ records in Production that this is constantly trying to find a value for and it is unable to since there is no VendorEntityItem data to pull from. This query runs about 4 times per day and has started to time out.

Most of this data already has the ReportingUnit already set (I assume from imports or other means) but it is still cranking on this data until there is enough VendorEntityItem data to set to the StockTakeUnit1.

So, there are a few ways I feel like we could shore this up:

1) I can ignore data where StockTakeUnit1 is null if "PerformStockCount" is 0. If we are not counting this data, do we need StockTakeUnit1

2) Default StockTakeUnit1 to the ReportingUnit (or something else) when we do not find VendorEntityItem data. The worry here would be that we set the StockTakeUnit1 to the ReportingUnit after the VendorItem import but then VendorEntityItem data shows up in the next import that we should have actually used instead.

3) Completely rewrite this based on discussions around these related Items:

https://cfacorp.atlassian.net/browse/INF-13 - this is the only change we have made to this code from Trunk. It fixes a bug where the Largest was not correctly getting used.

CFAMX-1861 - I do not think we changed anything, just confirming this still runs

CFAMX-2017 - I am not sure anything was actually resolved by this one other than manually updating Testing database. I think that the confusion here is that the way this process is set up it is only going to update data where ReportingUnit or StockTakeUnit1 data is not yet set. Once these are set, this process does not appear to be meant to Update this data to new, larger values that may get added to VendorEntityItem data at any other time. The reason for this is that this particular query is not meant to run on large volumes of data. If we try to force it to scan all data and do updates from new data, this would take minutes to run, and based on what I am seeing now, most likely time out. If the expectation is that this should be rescanning all EntityItems for updated Unit data, then this would have to be drastically rewritten and provided significantly more time to do this.