Another possible route could be to always drop your created report object when you are done.  To do this, you will need to first return the value returned by oSession.GetObject("SO_SalesOrderPrinting_rpt") into a numeric variable, could use something like this.

SONo = ""
oSOPrint = ""
oPaperless = ""
SOEntered = ""

retVal = oBusObj.GetValue("SalesOrderNo$", SONo)
retVal = oBusObj.GetValue("UDF_SO_ENTERED", SOEntered)

if SOEntered = "Y"  then
	nSOPrint = 0 : nSOPrint = oSession.NewObject("SO_SalesOrderPrinting_rpt") ' Return this into a numeric variable so it can be dropped later since the oSession.DropObject method does not support VBScript Objects passed as an argument and i have not been able to figure out a way to convert or extract a VBScript object back to a numeric handle like Sage 100 uses.
	If nSOPrint <> 0 Then
		Set oSOPrint = oSession.AsObject(nSOPrint)

		retVal = oSOPrint.SelectReportSetting("ISCORDER")

		oSOPrint.QuickPrint = SONo

		'Set EmailSelected property to true
		oSOPrint.EmailSelected = 1

		'Set Paperless options
		Set oPaperless = oSession.AsObject(oSOPrint.coPLCommon) ' Get Paperless object

		oPaperless.FormPrintUISelection = "2" ' Number of selection in dropbox on the Sales Order Printing Screen

		' Set Email Engine EESilent property to true
		'oSOPrint.EmailEngineObj.nEESilent = 1

		' Set Electronic Delivery.  Third argument is the email engine object handle for the from 	object.
		' Seventh argument is set to true to force no UI when processing

		retval = oPaperless.ElectronicDelivery("",0,oSOPrint.EmailEngineObj,0,"","",1)

		retVal = oSOPrint.ProcessReport("PRINT")
		set oSOPrint = Nothing
		' retVal = oBusObj.Clear()
		oSession.DropObject nSOPrint ' Drop the numeric object handle for the class created using GetObject/NewObject
	End If
End if

I know I have said you're a genius, but FOR REAL!  That worked GREAT!  
Thank you SO much.  I had no idea about the numeric variable trick, but I'm keeping that in my back pocket.

If i have the option, i always return sage 100 object handles into numeric variables first for three reasons.

1. Test if the variable is not equal to zero to make sure it is a valid object handle before using AsObject on it.
2. In case i need to drop it using oSession.DropObject.
3. In case i need to store the object handle so it can be accessed in a later event or from a different object event by using either oScript.SetStorageVar or oSession.AsObject(oSession.ScriptObject).SetStorageVar.  The former is usually used for when you need to reference the object handle (or any other variable value) from different events on the same business object.  The later is used for when you need to reference the object handle (or any other variable value) from different events from different business objects running under the same oSession session.

Man... I found a weird glitch with this and I can't figure out what would fix it.

So the script works wonderful when creating a new order.  Even when going back into an existing order and checking the UDFs needed to fire the script, it works.  HOWEVER, if there is a change in the lines tab (changing quantities or unit price, or making a change the triggers a discount) and you click on Accept, the script will trigger correctly but the PDF printed does not reflect the changes on the lines.  While the totals on the printed SO shows the new amount, it shows the previous lines before any changes.  It's almost as if the line changes do not write to the record before the script launches.  The script is a Table-Post Write so it should technically print AFTER the changes have been written to the table, no?  

To test, I created a new Accept button that all it does is click on the Totals tab if the Accept is pressed from any tab other than the Totals tab.  If the user clicks on the Accept button while on the Totals tab, then it will accept the order and the original SO Print script will launch.  I was hoping going to the Totals tab would trigger a recalc but it doesn't - at least not on the lines themselves. 

Anyone have any ideas?  Thanks in advance.

I had that issue doing something similar in the past.  It appears that even on the Post Write event, the script runs before the data is truly written to the tables.  I believe I found this documented.  I could not find a way around it.  We ended up do a scheduled script to print them.

Thanks for your reply.  I am glad someone else experienced the same thing, although not too excited about the outcome, though.  

If this is indeed the case - where Sage does process the script BEFORE the record is written to the table, I assume this would be a bug.  Now, the customer in question is on Sage 100 2018 and will be going to 2020 later this year.  Not sure if this is happening in those versions as well.