Are you looping through lines at all?  If so, you can throw the UI out of synch with the business object... where a grid refresh helps.  Here are my notes on how to deal with this... originally suggested by Alnoor.

I have found that sometimes adding a line programmatically in the sales order sets the TaxableAmount and NonTaxableAmount values for the sales order to 0.00 even though the lines add up to a value. I have to go in through DFDM to fix it manually. It happens randomly.

DFDM is not needed... change the Tax Schedule to something else, then back.  This trick forces the totals to be recalculated.

Kevin M No loops, just that single statement. It's the ENTIRE script. I purposefully isolated the screen corruption it to as small a script as possible. I did try the grid update trick, but it didn't help.

Perhaps try InvokeChange instead?  I'm not sure on the syntax for a grid value, but I think someone posted an example somewhere...

If CBool(oScript.UIObj) Then ' use invoke change so the UI is refreshed properly
	Set myUIObj = oSession.AsObject(oScript.UIObj)
	'retVal = oSession.AsObject(oSession.UI).MessageBox("Setting freight amount through InvokeChange")
	retVal = myUIObj.InvokeChange("FreightAmt", nManualFreight)
	Set myUIObj = Nothing
else ' otherwise just set the value
	retVal = oBusObj.SetValue("FreightAmt",nManualFreight)
End If

Kevin M Thanks again. I also tried this for the field (ItemCode) that experiences the corruption without success. By my isolating this to an easy to recreate issue across multiple current versions I had hopes that either jepritch or Natasha Chang would comment or forward to engineering.

Line level scripts on events like post-read, pre-write or post-write tend to cause this because of the way the UI object tracks movement between rows in a grid to determines if a line write is needed if the line you came from had been edited. 

I believe this has come up a few times before but mostly on the pre-write event because column level events don't cause this.  I believe I have posted a few different ways to get around it, one would be to figure out the last row and use the ShowRow method on it, another one would be to delay the setting of the value by using the CMD_STR$ variable.

This thread has some examples.

(+) Strange Behaviour when Setting a Date UDF from Button Script - Business Object Interface - Sage 100 - Sage City Community

Here are additional threads that include some of my posts on CMD_STR$.

(+) Changing a date field on a new line with an unrelated Pre-Write script also changes that date's format - confuses customer - Personalization, Customization, and Productivity Tools - Sage 100 - Sage City Community

(+) 2016 - 2020 First oScript.SetError Method doesn't trigger an error message in Lot/Serial Number Distribution - Personalization, Customization, and Productivity Tools - Sage 100 - Sage City Community

(+) Script advance to next line - Business Object Interface - Sage 100 - Sage City Community

Unfortunately this does not work. We tried changing the tax schedule to NONTAX then changing it back and it just went back to 0.00 for the Taxable Amount.

That sounds like a corrupted value / script / enhancement somewhere.  It always works for us (when done manually... not by script).