One of the biggest advantages in Dexterity is the Cross Dictionary access. There are so many 3rd party verticals being developed for Dynamics GP to meet the requirements of various Customers around the globe. And each one can be customized again to meet a very specific requirement from a Customer. The best way to achieve this is by Cross Dictionary Coding.

What exactly is a Cross Dictionary Customization? Any addition / change of functionality in a 3rd Party product involve a dictionary which is other than Dynamics.dic. Technically, we have direct access only to Dynamics.dic and its resources. Any customizations can be done directly on Dynamics.dic and the same is not true for dictionaries (or products) other than Dynamics. A change/addition to any dictionary (or product) which is other than Dynamics GP (Dynamics.dic) is considered to be Cross Dictionary Customization.

Why this is so difficult compared to Standard GP Customization? Simple reason, we do not have direct access to the other dictionary (product) resources at runtime. For instance, I cannot access a table from Project Accounting directly by referring to its Technical Name in my custom dictionary. It is the same for Forms, Reports and other resources. That makes the life of a developer miserable most of the times.

What is needed for a Developer to carry out such Customizations? Thorough idea of 3rd Party product on which he/she is going to do the customization. For instance, if I need to write an additional validation on HR Card functionality, I should know better about this form and its scope. I should be able to foresee the impact which my code is going to make on this form and the subsequent processes. This is a real tough challenge for any GP developer, since not everyone knows everything about all the 3rd Party products and its’ functionalities. Also, a developer should possess tremendous analysis and troubleshooting skills, such as the ability to take and study thru’ the Script Logs, Profiles, etc. These will be the base for most of the Cross Dictionary Customizations.

What are the methods with which we can develop Cross Dictionary Customizations? We do not have definite methods defined, but thru’ experience and the technical feasibility, we can confine the methods to the following three:

1. Construct SanScript code and pass the code to get it executed on the target 3rd Party Product.
2. Write 3rd Party Object and/or Event Triggers, just as we write on Standard GP objects or events.
3. Do a Developer Update of the target 3rd Party product with Dynamics and start customizing the screens and/or reports, depending on the actual requirements.

While all the above 3 points sound very simple, there are so many complications involved in using these methods and succeeding on our tasks.

Complications lie in finding the scope of our task in and around the 3rd Party functionality. Code needs to be written in such a way that the parent functionality should not be compromised (unless needed).

Coming back to the points listed above. The first point is widely used to retrieve any data from either window fields or tables of that particular product. This is used along with the 2nd point, to do some extensive customizations.

For instance if I need to fetch the “Employee Name” from the HR Employee Maintenance form, the following code piece will solve the purpose:

local string l_sEmployeeID, l_sCompileMsg;
local text l_sDexCode;
local integer l_nResult;

l_sDexCode = “”;
l_sDexCode = l_sDexCode + “out string O_sEmployeeID;”;
l_sDexCode = l_sDexCode + “O_sEmployeeID = ‘Employee ID’ of window UPR_Employee_MNT of form UPR_Employee_MNT;”;
l_nResult = execute(414, l_sDexCode, l_sCompileMsg, l_sEmployeeID);
if l_nResult 0 then
warning l_sCompileMsg;
end if;

The function execute() is used to compile and execute any SanScript code at runtime on any dictionary, either Dynamics or 3rd party. Syntax and prototype explanations can be referenced from the Dex Developer Compiled Help Manual.

It is very simple to construct such code pieces. But the most important thing is the Product ID (first parameter passed to execute() function). We should make sure that we have entered the correct product ID so that it gets executed correctly on the target product.

To be continued…

Vaidy