March 25, 2010 in Blog by Amer

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.

March 13, 2010 in Blog by Amer

Invoking AIF Sales Order Service creates Journal Type Sales Order!

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*/