In summary, when you add a field to Visual Basic from Microsoft Dynamics GP, the name of the field is set to the text in the the linked prompt for that field (or the caption text for buttons). If there is no linked prompt, the name of the field is set to the name of the Dexterity field (with any spaces removed). There is a problem when that field name is the same as a Visual Basic for Application (VBA) keyword or reserved word.
A couple of really common examples are the Date field and the Print button, where Date and Print are reserved words in VBA. When you attempt to use those fields, they are interpreted as the reserved word command and not a field name. Unlike SQL Server which can surround the field with [square brackets], there is no method to force VBA to use the keyword as a field.
I did some background research and did find a couple of Knowledge Base (KB) articles which refer to the same issue.
To demonstrate the issue and the solution, here are a series of screenshots.
On the Sales Transaction Entry window, I want to add the Dexterity ‘Document Date’ field to Visual Basic. I have already Added the Current window to Visual Basic, so now I select Add Fields to Visual Basic …
I then click on the Date field (highlighted below). Note: The prompt text is “Date”.
Once I select to go to the Visual Basic Editor and click on the SalesTransactionEntry module under the Microsoft_Dynamics_GP project, I can select the Date field from the drop down list to see its properties. Note: The only property available is the Name.
Once I edit the Name property so that it is no longer a reserved word, for example: DocumentDate, the rest of the window field’s properties are available.
After changing a field name, just make sure that any code written now references the updated name for the field and everything will work as expected.
Hope this helps.