Those who still love and live with Dexterity, David has given us (yeah I am also a die-hard Dexterity Developer) a great news.

Go thru’ his article: Statement of Direction for Microsoft Dynamics GP

I will be back with some more points on his other articles.

Until then…

Vaidy

All,

This is a query from Arun Prasath, one of my friends:

How to enable GP users to log on to Personal Data Keeper (PDK). Where the setup needs to be done?

Arun, I have uploaded the Documentation Manual for PDK on Google Docs (An invitation has been sent to your ID), which explains the Installation Setup and Configuration. While I have no clue about what this does, as I am yet to see this product, I would add points to this post, whenever I gain more knowledge on this.

Vaidy

It’s Festival Season now…

Recently I faced a question: Can we enter Intercompany Transactions in Sales & Purchasing, and if yes, how.

I knew for sure that there is no provision for Intercompany Transactions in Sales (I believe I am correct, in case I am wrong please do correct me). And I also knew there is certainly a provision in Payables which denotes a transaction being an Intercompany Transaction. But it did not strike my mind at that time. I felt bad that I could not remember such an easy point. I went back to my machine and did some GP surfing. Below is the gist of what needs to be done to enter an Intercompany Payables Transaction.

1. Make sure that the Intercompany Setup is complete for the Destination Company, with Due to / Due From Accounts setup. Also make sure that the option “Enter Corresponding Company ID” is selected. This will allow us to modify the Company ID in PM Transaction Distribution.
2. While entering the PM Transaction, make sure that as soon as you entered Voucher Number, you have selected the option “Intercompany”. This will tell the system that this transaction is an Intercompany Transaction.
3. The destination company distributions must be of types PURCH, FNCHG, FREIGHT, MISC or UNIT. Others are not supported.
4. You cannot post an Intercompany Transaction directly. Any IC Transaction must be saved in a batch. If the transaction is of the same currency, then it can be stored in either Single Use PM batch or Recurring PM Batch. If the transaction is of different currency from that of the destination company (Multi-Currency Transaction), then we should save the transaction only on Single Use PM batch.
5. On posting the Intercompany PM Transaction, a General Ledger batch will be created in each company. This batch must be posted to become a permanent part of the records of the company.

I guess I have covered all important points with respect to PM IC Transaction. Please do add/change/remove the points if it is needed.

Now, I may be silly in asking this, I would like to understand “why logically an Intercompany Sales cannot happen”. And I would love to understand Intercompany Transactions more from Business & Functionality point of view.

Vaidy

Guys, David is certainly at his blogging spree I believe and we are left with 3 valuable articles. The articles are in the following sequence:

1. zDP Stored Procedures (fondly called Dex Auto Procs) are the backbone of Dexterity table operations. Each “get table”, “save table”, “remove table”, “range table” statement lives with at least one zDP stored procedure. David starts with the evolution of GP Table operations and then the necessity of zDP procedures and then finally comprehensive information on each zDP notations. While “how Dex commands are in turn calls a zDP proc” is still a mystery for me, I did learn a lot from this article about zDP_s. Please do read this article on: What do the zDP_ Auto Generated Stored Procedures do?.

2. Finding all the necessary information on GP Tables & Resources, is a bit of menace of beginners and sometimes even for a Novice Dex Programmer. For those guys, this article is a “Dex”ipedia in itself. While this has been already gathered and written on Steve’s, Victoria’s and Mark’s blogs, this article does a consolidation of all with even more references to look out for. This article also advises us to refer “What, When and Where”. Original Link: Finding Table and Field Information in Microsoft Dynamics GP.

3. VSTools were literally the last option for most of the developers due to various incompatibility with Dynamics GP and honestly the complex coding involved. One of the major issues, was the Scrolling Window accessibility (atleast a simulation of sorts). And even precisely, filling the Scrolling Windows from VSTools coding. This article is a MUST READ, as it covers almost all the details of LineFill event in VSTools for Scrolling Windows, except the Syntax and other techincal details. I am a strong believer in understanding the concepts of any tool, scope of it and limitations. This article will enlighten us in that aspect. Original Link: Visual Studio Tools LineFill Events.

For Beginners, Novice and even Experts, these 3 articles are “The References” to look out for.

There is a word from Mariano on his blog, which I would like to stress once again: “The only reward we get from blogging — besides sharing our knowledge — is to know that you are following and enjoying these articles as much as we enjoy writing them.”.

Very true. The ultimate reward for someone who shares his/her knowledge with everyone, is to know that the knowledge shared reached the right people in the right spirit and that it’s helpful to improve our own skills.

I am desiring for more such articles in future from David and Team.

Vaidy

While I am going to talk about eConnect, I would like to disclaim that the explanations are JUST out of my understanding of the concepts of eConnect and the structure. Please do refer to some more articles from Microsoft, Consultants worldwide and others to know more about this and also correct my own understanding in case you find it irrelevant.

eConnect use Windows Authentication to converse with GP Databases instead of the traditional SQL Authentication (which GP uses). There could be various reasons why it is designed in such a way. I am listing some of the important reasons:

1. eConnect does not require GP Application, or precisely, it does not depend on an Instance of GP Application to be running (which is the case with Integration Manager for most of its Integrations). This would mean that, the login credentials for an eConnect integration cannot be inherited from anywhere. We still have to establish a Connection String (ODBC) to the GP Databases to access the data and manipulate it.

2. eConnect is designed to run in the background and access/manipulate the GP databases without anyone’s idea of what’s going on with the records and database. Apparently, there should be a kind of authentication which is much more stronger than the basic SQL Authentication, which the Windows Authentication provides us.

3. eConnect is the base for almost all the web based features we have for Dynamics GP, such as Webservices, Business Portal, etc. We cannot have a compartively weaker Authentication level when we allow anyone to access GP Databases from anywhere.

4. eConnect can utilize MSMQ (Microsoft Message Queuing), to queue the integrations from anywhere to the Dynamics GP server. In such cases, it has to have a Windows Authentication to pass the MSMQueuing validations.

I am still learning more concepts on these two Authentications and its scope with respect to GP and related products. I will update more points with references, so it does not just go in as a theory.

Vaidy

Syntactically, we cannot use the “abort script” statement inside a “try … end try” block, which is a limitation (or may be for some logical reason) in Dex.

But most of the times, “abort script” is indeed a boon for most of the scenarios, where we need to skip the further processing of that particular script. How to overcome this?

We can simulate this “abort script” inside a “try … end try”. Check out the following code:

try
{regular code pieces}
if ProcessFurther = false then
throw EXCEPTION_ABORT_SCRIPT; {You can create this constant for reusability on your code with some integer value which you think is not used for any other System Exceptions}
else
{Proceed further}
end if;
catch
{Handle the Exceptions}
catch [EXCEPTION_ABORT_SCRIPT] {Your own Exception defined}
{Just do nothing. This is to simulate the “abort script” functionality.}
end try;

This is an easy way to simulate the “abort script” inside a “try … end try” block.

Other possibilities are most welcome.

Vaidy