Browsing all articles tagged with Ledger Journal Archives - Amer Atiyah, Microsoft Dynamics 365 Blog
6
Sometimes you might face an unexpected error when trying to insert new records to any of the Dynamics AX tables. The message you might have is like: Cannot create a record in Journal lines (LedgerJournalTrans). The record already exists.
You might also have tried to check the indexes of this table that shouldn’t be duplicated. And you got surprised when you are not violating those constraints, so there is no any rational reason why this error might appear.
After so many tries, I got to fix that error by:
  1. Backing-up my database (just in case that anything went wrong)
  2. Exporting the data of that table (from the AX Import/Export functionality)
  3. Deleting/Dropping the table from the Microsoft SQL Server Management Studio (by this all the data of course will be deleted)
  4. Opening the Dynamics AX client, going to: AOT –> Data Dictionary –> Tables –> LedgerJournalTrans –> Right clieck –> Synchronize
  5. Importing the data again to all companies (from the AX Import/Export functionality.

As you could see, I got this error in a very critical table that is the LedgerJournalTrans table. This table contained already posted lines and it was really headache for me to get it fixed. But fortunately I was able to fix it by following the previous steps. :)

0

What is LedgerJournalFormTrans Class?

If you ever tried to modify the LedgerJournalTransDaily form (the Ledger Jourlan Lines form) you would notice a forest of X++ codes executed on every click, initializations, closing, fields modifications… etc. Of course this makes sense because this form is basically the backbone of financial transaction of this Dynamics AX, which in turn the backbone of all modules of Dynamics AX.

One of the common classes executed in this form is LedgerJournalFormTrans class. Basically this class controls the controls of any form where LedgerJournalTrans table is a datasource for that form. It simply controls the visibility, edibility and validity of most of the controls on that form based on the “status” of the current Ledger Journal Trans and Ledger Journal Table. Whenever a user fills data, reads data, and clicks buttons and menu buttons.. a call for a method in that class is executed to control the new write/read/event.

Actually LedgerJournalFormTrans is an important class of a series of extended classes. Those classes are like the following:

  • JournalForm --> JournalFormTrans --> LedgerJournalFormTrans --> LedgerJournalFormTrans_Payment
  • JournalForm --> JournalFormTable --> LedgerJournalFormTable 

I believe from the name you could tell what all of those classes are all about.

1

If you ever called the AIF Sales Order Service in Dynamics AX 2009, then you had to specify the Customer Requisition (PurchOrderFormNum) field in SalesTable although this field is not really mandatory.

The Sales Order web service assumes that it is called from trading partners applications. Thus, whenever a sales order is created, this means that it has been created based on a request (Purchase Requisition most of the time) by this trading partner to your organization. And this requisition should be recorded in the PurchOrderFormNum field.

But why does the AIF Web Service create Journal type sales order then? The AxdSalesOrder class (the AX Document class) checks whether this sales order has been requested before by this customer (CustAccount field) or not. If it has been requested before, then this means that this customer (the one who sent this sales order document via the AIF Sales Order service) is purchasing based in the same Sales Order.. so Dynamics AX does not need to create another sales order, it creates Journal type sales order instead for the same customer and the same Customer Repulsion.

A great detail of the Sales Order Document Service is found in this link: http://msdn.microsoft.com/en-us/library/cc967401.aspx.

You might face the same scenario that I’m facing with one of my customers currently, that is migrating sales orders from an internal legacy system where you want only to migrate sales orders without checking for a Customer Requisition. If this is what you’re looking for, then all what you have to do is to comment the code in AxdSalesOrder class and prepareSalesTable method:

select firstonly localSalesTable
where 	localSalesTable.CustAccount 		== _axSalesTable.parmCustAccount() &&
	localSalesTable.PurchOrderFormNum 	== _axSalesTable.parmPurchOrderFormNum() &&
	localSalesTable.SalesId           	!= _axSalesTable.parmSalesId();
 
/*COMMENT FROM HERE
if (localSalesTable)
{
	_axSalesTable.parmSalesType(SalesType::Journal);
}COMMENT TO HERE*/

Dynamics AX 2012 Event

Recent Posts

Tags

Archives

Random Testimonial

  • ~ Mohamad Adel, Sr. Dynamics AX Developer at Al-Fanar IT

    Adel"I recommend Amer Atiyah as i worked with him in many simple and complicated tasks and i realized that he is very intelligent in the way of thinking to solve tasks problems. He has a very good experience and knowledge of his job. He is very hard worker, committed, organized and creative and very open mind in his work and that is the reason if his brilliant in his specialized field. He is always showing a high degree of professionalism and ability to deliver and accomplish very complicated tasks at any condition with high quality. I am recommending him to work in any team and i know he will fit with all challenges. Purely, he is a professional guy. I wish to him more and more success in his career and his life."

  • Read more testimonials »