A baffling bug in a modified SOP Transaction Entry window

By Steve Endow

A customer called me today asking for help with a GP customization.

They have a modified SOP Transaction Entry window and a modified SOP User Defined Fields Entry window.  The SOP Trx Entry window has two custom buttons and a little bit of VBA script, while the SOP UDF window has some fields hidden to simplify it, along with a custom button that opens a custom VBA window.

Pretty basic modifications--nothing special.

The client demonstrates that when they open the SOP UDF field, enter some values in the fields, then click on OK, then save the parent SOP Invoice, the SOP UDF values are not saved.

If they open the same invoice and then open the SOP UDF window, the fields are all blank.

Hmm, that's interesting.

But wait! There's more!

They tested different scenarios, and figured out that if they do not use the modified SOP Trx Entry window, the modified SOP UDF window does save properly.

Yes. You read that right.  If they revert to the standard GP SOP Trx Entry window, their modified SOP UDF window saves values and retrieves them properly.

So, it seems that for some reason, the modified SOP Trx Entry window breaks the SOP UDF window.

I ran a SQL Profiler trace on the SOP UDF window while using the modified SOP Trx Entry window, and here is what I saw.

BEGIN INSERT INTO TWO.dbo.SOP10106 (SOPTYPE, SOPNUMBE, USRDAT01, USRDAT02,

USRTAB01, USRTAB09, USRTAB03, USERDEF1, USERDEF2, USRDEF03, USRDEF04, USRDEF05,

COMMENT_1, COMMENT_2, COMMENT_3, COMMENT_4, CMMTTEXT)

VALUES ( 0, '', '1900.01.01' ....

Notice that SOPTYPE = 0 and SOPNUMBE = ''

And that statement produces an invalid record in SOP10106.

When I disable the modified SOP Trx Entry window, but keep the modified SOP UDF window, things return to normal.

BEGIN INSERT INTO TWO.dbo.SOP10106 (SOPTYPE, SOPNUMBE, USRDAT01, USRDAT02, USRTAB01, USRTAB09, USRTAB03,

USERDEF1, USERDEF2, USRDEF03, USRDEF04, USRDEF05, COMMENT_1, COMMENT_2, COMMENT_3, COMMENT_4, CMMTTEXT)

VALUES ( 3, 'STDINV2263' ....

Notice that the values for SOPTYPE and SOPNUMBE are populated.

Very, very strange.  Somehow, the modified SOP Trx Entry window is preventing the SOP UDF field from having the SOP Type and SOP Number values.

This set of modified SOP windows works fine on their old GP 2010 environment, but exhibits this problem on their current GP 2015 environment.  The modified forms did have some errors and problems when upgraded to GP 2015, so that may be a clue, and I don't know if they might have made a change that caused this issue.

But regardless, I found it a rather strange problem to have.

My recommendation is to recreate the modified SOP Trx Entry window from scratch and see if that solves the problem.  If not, also recreate the modified SOP UDF window from scratch.  The modifications shouldn't take long to reproduce, and I suspect that will be much easier and cleaner than trying to figure out the specific cause of the problem.

I'm always amazed at the strange things I continue to see.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com