Book Image

Microsoft Dynamics AX 2009 Development Cookbook

By : Mindaugas Pocius
Book Image

Microsoft Dynamics AX 2009 Development Cookbook

By: Mindaugas Pocius

Overview of this book

Microsoft Dynamics AX provides a comprehensive Enterprise Resource Planning (ERP) solution for mid-size and larger organizations. Dynamics AX implementations are used worldwide by thousands of customers. With the new version - Dynamics AX 2009 - the system is due to expand even more rapidly. Every new implementation requires some level of customization, and all organizations want this to be done to the highest standards using proven approaches. This step-by-step guide will help you manage your company's ERP information and operations efficiently, and solve your business process problems in an effective and quick way. This book focuses on commonly used custom modifications in major Dynamics AX modules. This book contains commonly used bits of code which were real-world tested in at least one successful Dynamics AX implementation. Many of the recipes were deployed in many implementations and even across several versions of Dynamics AX. The examples in this book cover various areas of Dynamics AX to help developers not only learn about programming, but also about the functional side of Dynamics AX. The book should help developers who already know the basics of Dynamics AX programming to step up to the next level. The recipes allow you to look at the development from the perspective of business processes. You will learn to enhance your user interface using various Dynamics AX UI elements. Managing your data and functions will become easier. You will also get numerous development tips and tricks from a Dynamics AX development expert.
Table of Contents (12 chapters)
Microsoft Dynamics AX 2009 Development Cookbook
Credits
About the Author
About the Reviewers
Preface
Index

Merging two records


I noticed that sometimes for various operational reasons, people by accident create duplicate records in the system like vendors, customers, ledger accounts, etc and start entering transactions against them. The reasons could vary from rushing to input new information to the lack of knowledge of how to use the system. But regardless of why this happened, they will always need someone with technical skills to fix it.

In this recipe, we will explore how to correct such a situation by merging two records including all their related transactions. For the demonstration, we will merge two vendor accounts 5001 and 5002 into a single one, that is, 5001.

How to do it...

  1. Open AOT, create a new job called VendAccountMerge, and enter the following code:

    static void VendAccountMerge(Args _args)
     {
         VendTable               vendTable;
         VendTable               vendTableDelete;
         PurchJournalAutoSummary jourSummary;
         #define.vend('5001')
         #define.vendDelete('5002')
         ;
     
         ttsbegin;
     
         delete_from jourSummary
             where jourSummary.VendAccount == #vendDelete;
     
         select firstonly forupdate vendTableDelete
             where vendTableDelete.AccountNum == #vendDelete;
     
         select firstonly forupdate vendTable
             where vendTable.AccountNum == #vend;
     
         vendTableDelete.merge(vendTable);
         vendTable.doUpdate();
         vendTableDelete.doDelete();
     
         ttscommit;
     }
  2. Open Account payable | Vendor Details to check the vendors to be merged:

  3. Run the job to merge the vendor accounts.

  4. Open Account payable | Vendor Details to see the results:

How it works...

Once vendor accounts are merged, all their related records are going to be merged too, that is, all transactions, contacts, addresses, configuration settings, and so on from both vendors will be moved to a single one. Normally, there are no issues with merged transactional data, but vendor configuration settings may issue duplicate errors.

For example, vendor 5001 has bank account Bank1 and vendor 5002 has bank account Bank2. After merging both vendors, vendor 5001 will have both bank accounts attached. If both bank accounts were named the same, then the system would issue a duplicate record error.

So before we start merging records, we need to either manually or programmatically delete or rename settings that might issue duplicate errors. In this example, in the first block of code, right after the variable declaration, we delete only the default auto-summary posting settings, which are stored in the PurchJournalAutoSummary table. Depending on the circumstances, other settings like vendor bank accounts, requests for quotes, and so on, have to be corrected before the actual merge.

Next two blocks of code find both vendor records for further updating.

Calling member method merge() on the record to be deleted transfers all of its data and related records to the destination, which is specified as a first argument.

The last thing to do is to save the destination record and delete the first one.

Such a technique can be used to merge two or even more records. Besides vendors, it could also be customers, ledger accounts, and other such similar records. Every case has to be investigated separately as each record type contains different relations with other tables.