#Dexterity Remember Multicurrency when Customizing Transaction windows

David Meego - Click for blog homepageI was asked recently to assist with some custom code that had been added to a transaction window in Microsoft Dynamics GP. The customization would work for one user, but not for a different user.

The customization was created using GP Power ToolsDeveloper Tools module, but similar code could have been created using Dexterity, Visual Studio Tools or even VBA (Visual Basic for Applications).

Many transaction windows in Microsoft Dynamics GP support multicurrency functionality and some even have user selectable views between functional currency, originating currency and some even support a third reporting currency view.

When the issue was described to me and I realized that the part of the custom code that was failing was using a trigger on a currency field on the window, I asked them to compare the currency view between the working user and the non-working user. The views were different and changing the view back to functional currency allowed the customization to work.

The customer was not using multicurrency and changing the view for a functional currency transaction does not look any different to the users. As the currency view is saved for each user, users with Originating Currency view would not work when users with Function Currency view would work.

Many of these windows implement multicurrency using two or three sets of currency fields overlaid on top of one another. Changing the view just shows the set of fields for the desired view and hides the other sets of fields.

This means that if you need a trigger on one of these currency fields, you will actually need to add multiple triggers, one for each of the overlaid fields. For example:

‘Trade Discount Amount’
‘Originating Trade Discount Amount’
‘(L) Trade Discount Amount’

The exact field names might differ for each transaction window as the implementations are not always the same. In our case, adding a second trigger to the originating currency field resolved the issue.

While I am warning developers about potential “Gotchas” when customizing transaction windows, here is one more bit of advice. If the window has a line detail window, make sure that the customization is also applied against this window to ensure a consistent user experience regardless of the window used. For example:

Sales Transaction Entry (SOP_Entry)
Sales Item Detail Entry (SOP_Item_Detail)

Hope this information is useful.


This article was originally posted on http://www.winthropdc.com/blog.

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.