Set up excise taxes in Dynamics AX

In regard to implementing Excise tax in Saudi Arabia, I would like to share the link below to all companies have been implemented Dynamics AX 2012 

https://docs.microsoft.com/en-us/dynamicsax-2012/appuser-itpro/pol-set-up-excise-taxes

How to Delete Company Transactions in AX 2012 including Trial balance?

To delete Transactions data inside any company in ax, you can do by using the class SysDatabaseTransDelete under AOT.

But you may facing an issue since the Trial Balance will not be deleted so, to delete GL Trans by deleting the following tables:

GeneralJournalAccountEntry

GeneralJournalEntry

LedgerEntryJournal

LedgerEntry

Ledgerjournaltrans

Ledgerjournaltable

To remove the Trial Balance you have to follow the steps below:

1-) Modify 'handleTable()' method by adding 2 new cases

Case TableGroup::TransactionHeader:

Case TableGroup::TransactionLine:

void handleTable(SysDictTable sysDictTable)

{

    TableGroup      tableGroup;

    if (tableSet.in(sysDictTable.id()))

        return;

    tableSet.add(sysDictTable.id()); 

    if (sysDictTable && !sysDictTable.isTmp() && !sysDictTable.isMap())

    {

        tableGroup = sysDictTable.tableGroup();

        // Handle company specific tables to be deleted

        if (sysDictTable.dataPrCompany())

        {

            switch(tableGroup)

            {

                case TableGroup::Transaction:

                case TableGroup::TransactionHeader:

                case TableGroup::TransactionLine:

                case TableGroup::WorksheetHeader:

                case TableGroup::WorksheetLine:

                    this.handleTransTable(sysDictTable);

                    break;

                default:

                    this.handleNonTransTable(sysDictTable);

                    break;

            }

        }

        else

        {

            // Handle global tables to be deleted

            switch(tableGroup)

            {

                case TableGroup::Transaction:

                case TableGroup::TransactionHeader:

                case TableGroup::TransactionLine:

                case TableGroup::TransactionHeader :

                case TableGroup::WorksheetHeader:

                case TableGroup::WorksheetLine:

                    this.handleGlobalTransTable(sysDictTable);

                    break;

                default:

                    break;

            }

        }

    }

}

2) Add a new method to handle LEDGERJOURNALTABLE:

private void deleteLedgerJournalTables()
{

    GeneralJournalEntry         GJEntry;
    GeneralJournalAccountEntry  GJAEntry;
    LedgerJournalTable          ledgerjournalTable;
    LedgerEntryJournal          ledgerEntryJournal;

    ttsBegin;
    while select forupdate LedgerJournalTable
    {
        while select forUpdate ledgerEntryJournal
            where ledgerEntryJournal.JournalNumber == ledgerjournalTable.JournalNum
            //&&    ledgerEntryJournal.dataAreaId == ledgerjournalTable.dataAreaId
        {
            while select forUpdate GJEntry
                where GJEntry.LedgerEntryJournal == ledgerEntryJournal.RecId
            {
                  delete_from GJAEntry  where GJAEntry.GeneralJournalEntry == GJEntry.RecId;

                GJEntry.delete();
            }
            ledgerEntryJournal.delete();
        }
        LedgerJournalTable.delete();
    }
    ttsCommit;
}

3) Modify the 'handleTransTable()' method to call the above method

void handleTransTable(SysDictTable sysDictTable)
{
    switch(sysDictTable.id())
    {
        case tablenum(CustCollectionLetterLine):
        case tablenum(InventDim):
        case tablenum(DocuRef):
        case tablenum(DirPartyRelationship) :

            break;
        case tablenum(LedgerJournalTable) : 
            this.deleteLedgerJournalTables();
            break;

        default:
            this.deleteTable(sysDictTable);
            break;
    }
}

4) You may have to modify the 'deleteVoucher()' method in the 'LedgerJournalTrans' table to skip over releasing non-existing voucher numbers

public server void deleteVoucher(Voucher _voucher = this.Voucher)
{
    LedgerJournalTable  ledgerJournalTable = LedgerJournalTable::find(this.JournalNum);

    if (! ledgerJournalTable.Posted && !this.Transferred)
    {
        if (_voucher && ! LedgerJournalTrans::existTransMinusThis(this.JournalNum, _voucher, this.RecId))
        {
            if (this.checkVoucherNotUsed(ledgerJournalTable, _voucher))
            {
                if (this.checkVoucherNotUsedDataSource(_voucher))
                {
                    // replace the voucher number so it can be re-used
                    if (ledgerJournalTable.NumberSequenceTable) /* 28Nov12-Admin */
                        NumberSeq::releaseNumber(ledgerJournalTable.NumberSequenceTable, _voucher);

                    if (this.Voucher == _voucher)
                    {
                        // delete voucher template record if exists and the voucher on the line is not being changed
                        LedgerJournalTransVoucherTemplate::deleteForJournalOrVoucher(this.JournalNum, _voucher);
                    }
                }
            }
        }
    }
}

5) After running 'SysDatabaseTransDelete', rebuild balances for the financial dimension sets (General Ledger\Setup\Financial Dimensions\Financial dimension sets)

If you still have non-zero amounts in the Trial balance then you must manually remove the 'left-over' rows in the shared tables (results of your previous executions of the 'SysDatabaseTransDelete'). Identify these entries in the 'LedgerEntryJournal' table then use the following job to clear them:

static void tg_deleteTables(Args _args)
{
    GeneralJournalEntry         GJEntry;
    GeneralJournalAccountEntry  GJAEntry;
    LedgerJournalTable          ledgerjournalTable;
    LedgerEntryJournal          ledgerEntryJournal;

    ttsBegin;
        while select forUpdate ledgerEntryJournal
            where ledgerEntryJournal.JournalNumber like 'clau*'  
        {
            while select forUpdate GJEntry
                where GJEntry.LedgerEntryJournal == ledgerEntryJournal.RecId
            {
                  delete_from GJAEntry  where GJAEntry.GeneralJournalEntry == GJEntry.RecId;

                GJEntry.delete();
            }
            ledgerEntryJournal.delete();
        }

    ttsCommit;
    info('completed');
}

Make sure that the X++ code has been compiled to Microsoft .NET Framework CIL - AX Batch Error

I developed custom class which extend RunBaseBatch system class to run in server, After created my class and run the class though batch job, there is an error is occurred and got the following error in log.

"Unable to construct an object from the class Sample Class in the batch framework. Make sure that the X++ code has been compiled to Microsoft .NET Framework CIL, and that the constructor does not require any parameters"

After search through internet I got solution by run “Generate incremental CIL” as  displayed below

Hint: May it takes time depend on server configuration.

Configure the workflow notification options [AX 2012]

Notifications may be sent to you when workflow-related events occur. For example, a notification may be sent to you when a document is assigned to you for approval or when the workflow process is completed for a document that you submitted. You can specify how you want to receive workflow notifications.

1. Click File > Tools > Options.

2. In the left pane of the Options form, click Notifications.

3. In the Receive notifications every (minutes) field, enter the number of minutes to specify how often you want to receive notifications.

4. In the Line-item notification type list, specify how you want to receive workflow notifications for line items from the following options:

   • Grouped – Notifications for line items are grouped into a single notification.

   • Individual – A notification is sent for each line item.

5. To receive notifications in the Microsoft Dynamics AX client, select the Show notifications in the Microsoft Dynamics AX client check box.

   If you select the Show notifications in the Microsoft Dynamics AX client check box, you can also specify whether you want to receive notifications as pop-up messages. To receive pop-up messages, select the Show pop-ups for notifications check box.

6. To receive notifications as email, select the Send notifications in email check box.

Walkthrough: Creating a Report Bound to a Report Data Provider Class (X++ Business Logic) [AX 2012]

In this walkthrough, you use a report data provider (RDP) class with business logic to process data and then display the outcome of the business logic on a report.

An RDP class is an X++ class that is used to access and process data for a Reporting Services report. The options for a data source type for a Microsoft Dynamics AX report are query, business logic, and RDP. An RDP class is an appropriate data source type when the following conditions are met.

1. You cannot query directly for the data you want to render on a report.
2. The data to be processed and displayed is from Microsoft Dynamics AX.

The following illustration is a preview of the report that you create in this walkthrough.

Note

The data that displays in your report may vary depending upon the sample data that is available to you.

The following elements are required to set RDP as your data source type.

• Temporary table – RDP class fills a temporary table with data that will be used by Reporting Services to display the report.
• Data contract class – defines the parameters in the report.
• Report data provider class – processes business logic based on parameters and a query, and then returns the tables as a dataset for the report.

This walkthrough illustrates the following tasks:

• Creating a temporary table
• Defining a report data provider class
• Defining the report parameters
• Defining a method to return data to Reporting Services
• Adding business logic for the report
• Creating a reporting project
• Binding a report to a report data provider class

Creating a Temporary Table

Data for an RDP report is preprocessed and then stored in a temporary table. The temporary table is used by Reporting Services when the report is displayed. A table returned by a method can be a temporary table (InMemory or TempDB) or a regular table. When the data returned is used for reporting only, it is a best practice to use a temporary table.

• Use an InMemory temporary table if the dataset is small, for reports that will display fewer than 1000 records.
• Use a TempDB temporary table for large datasets to improve performance.

In this section you will create a temporary table to store the data for the report.

To create a temporary table

1. In the AOT, expand the Data Dictionary node, right-click the Tables node, and then click New Table.
2. Right-click the table, and click Properties.
3. In the Properties window, set the Name property to TmpCustTableSample and set the Table Type property to TempDB. This will define the table as a SQL Server temporary table.
4. Expand the node next to the TmpCustTableSample table so that you can see the Fields node.
5. Press Ctrl+D to open another AOT window and move the window so you can see both AOT windows.
6. In the second AOT, expand the Data Dictionary node, expand the Extended Data Types node, and drag the following types to the Field node in the first AOT window:
   • AccountNum
   • CustName
   • LogisticsAddressing
   • CustGroupId
   • Phone
   • CustInvoiceAccount
   • ActionDays
   • InclTax
7. In the second AOT window, expand the Base Enums node and drag the CustAccountStatement enumeration to the Fields node of the first AOT window.

Defining a Report Data Provider Class

The RDP class is a data provider that allows you to add business logic for the data that is displayed on a report. The business logic for this example prompts the end user for parameter values, processes business logic to generate data in a table, and then returns the table to render in the report. In this section, you define the RDP class by extending the SRSReportDataProviderBase class. Then add the TmpCustTableSample table as a global variable. The following list describes the attributes that are attached to the RDP class for this example:

• Attach the SRSReportQueryAttribute attribute to specify the query to use to get the data for the report.

For this example, set the attribute to the Cust query.

• Attach the SRSReportParameterAttribute attribute to specify the data contract class that defines the report parameters for the report.

For this example, set the attribute to the SrsRDPContractSampledata contract.

To define a report data provider class

1. In the AOT, right-click the Classes node, and then click New Class.
2. Right-click the new class, click Rename, and then enter SrsRDPSampleClass.
3. Expand SrsRDPSampleClass, right-click classDeclaration, and then click View Code.
4. In code editor, enter the following code in the class declaration to define the class.

X++

[

SRSReportQueryAttribute (querystr(Cust)),

SRSReportParameterAttribute(classstr(SrsRDPContractSample))

]

public class SrsRdpSampleClass extends SRSReportDataProviderBase

{

TmpCustTableSample tmpCust;

}

Defining a Data Contract Class

An RDP class must have a data contract if the report has one or more report parameters. This example defines three report parameters for account number, account statement, and whether to include tax. When you print the report, you can specify which data to print based on the report parameters. For example, you can specify to only print transactions for account number 4000.

A data contract is an X++ class with getters, setters, and the DataMemberAttribute attribute. The data contract defines the parameters that the report uses.

To define a data contract class

1. In the AOT, right-click the Classes node, and then select New Class.
2. Right-click the new class, click Rename, and then enter SrsRDPContractSample.
3. Expand SrsRDPContractSample, right-click classDeclaration, and then click View Code.
4. In code editor, enter the following code in the class declaration to define the class.

X++

[DataContractAttribute]

public class SrsRDPContractSample

{

AccountNum accountNum;

CustAccountStatement accountStmt;

boolean inclTax;

}

A data contract class has methods with the DataMemberAttribute attribute. The name that follows this attribute is the parameter name that displays in Visual Studio when you bind a report data set to the RDP class. In this section, add a method for each of the report parameters and name them parmAccountNum, parmAccountStmt, and parmInclTax.

To define data contract methods

1. Right-click SrsRDPContractSample, point to New, and then click Method.
2. Edit the method so that it contains the following code.

X++

[DataMemberAttribute("AccountNum")]

public AccountNum parmAccountNum(AccountNum _accountNum = accountNum)

{

accountNum = _accountNum;

return accountNum;

}

1. Right-click SrsRDPContractSample, point to New, and then click Method.
2. Edit the method so that it contains the following code.

X++

[DataMemberAttribute("CustAccountStatement")]

public CustAccountStatement parmAccountStmt(CustAccountStatement _accountStmt = accountStmt)

{

accountStmt = _accountStmt;

return accountStmt;

}

1. Right-click SrsRDPContractSample, point to New, and then click Method.
2. Edit the method so that it contains the following code.

X++

[DataMemberAttribute("InclTax")]

public boolean parmInclTax(boolean _inclTax = inclTax)

{

inclTax = _inclTax;

return inclTax;

}

Defining a Method to Return Data to Reporting Services

A method to return the processed data in the temporary table to Reporting Services is needed. In this section, add a method named getTmpCustTable and attach the SRSReportDataSetAttribute attribute to indicate the dataset for the report.

To define a method to return the data to Reporting Services

1. Right-click SrsRdpSampleClass, point to New, and then click Method.
2. Edit the method so that it contains the following code.

X++

[SRSReportDataSetAttribute("TmpCust")]

public TmpCustTableSample getTmpCustTable()

{

select * from tmpCust;

return tmpCust;

}

Adding Business Logic for the Report

The business logic for this example prompts the end user for parameter values, processes business logic to generate data in a table, and then returns the table to render in the report.

The report business logic is provided in the processReport method. This method is called by Reporting Services at runtime. The following example illustrates how the processReport method computes data and populates the data table that is returned to Reporting Services. In this section, override the processReport method to provide business logic for your report.

To add business logic for the report

1. Right-click SrsRdpSampleClass, point to Override method, and then click processReport.
2. Edit the method so that it contains the following code.

X++

public void processReport()

{

AccountNum accountNumber;

CustAccountStatement custAcctStmt;

boolean boolInclTax;

Query query;

QueryRun queryRun;

QueryBuildDataSource queryBuildDataSource;

QueryBuildRange queryBuildRange;

CustTable queryCustTable;

SrsRdpContractSample dataContract;

// Get the query from the runtime using a dynamic query.

// This base class method reads the query specified in the SRSReportQueryAttribute attribute.

query = this.parmQuery();

// Get the parameters passed from runtime.

// The base class methods read the SRSReportParameterAttribute attribute.

dataContract = this.parmDataContract();

accountNumber = dataContract.parmAccountNum();

custAcctStmt = dataContract.parmAccountStmt();

boolInclTax = dataContract.parmInclTax();

// Add parameters to the query.

queryBuildDataSource = query.dataSourceTable(tablenum(CustTable));

if(accountNumber)

{

queryBuildRange = queryBuildDataSource.findRange(fieldnum(CustTable, AccountNum));

if (!queryBuildRange)

{

queryBuildRange = queryBuildDataSource.addRange(fieldnum(CustTable, AccountNum));

}

// If an account number has not been set, then use the parameter value to set it.

if(!queryBuildRange.value())

queryBuildRange.value(accountNumber);

}

if(custAcctStmt)

{

queryBuildRange = queryBuildDataSource.findRange(fieldnum(CustTable, AccountStatement));

if (!queryBuildRange)

{

queryBuildRange = queryBuildDataSource.addRange(fieldnum(CustTable, AccountStatement));

}

// If an account statement has not been set, then use the parameter value to set it.

if(!queryBuildRange.value())

queryBuildRange.value(int2str(custAcctStmt));

}

if(boolInclTax)

{

queryBuildRange = queryBuildDataSource.findRange(fieldnum(CustTable, InclTax));

if (!queryBuildRange)

{

queryBuildRange = queryBuildDataSource.addRange(fieldnum(CustTable, InclTax));

}

// If flag to include tax has not been set, then use the parameter value to set it.

if(!queryBuildRange.value())

queryBuildRange.value(int2str(boolInclTax));

}

// Run the query with modified ranges.

queryRun = new QueryRun(query);

ttsbegin;

while(queryRun.next())

{

tmpCust.clear();

queryCustTable = queryRun.get(tablenum(CustTable));

        tmpCust.AccountNum = queryCustTable.AccountNum;

        tmpCust.CustName = queryCustTable.name();

        tmpCust.LogisticsAddressing = queryCustTable.address();

        tmpCust.CustGroupId = queryCustTable.CustGroup;

        tmpCust.Phone = queryCustTable.phone();

        tmpCust.CustInvoiceAccount = queryCustTable.InvoiceAccount;

        tmpCust.CustAccountStatement = queryCustTable.AccountStatement;

        tmpCust.InclTax = queryCustTable.InclTax;

        tmpCust.insert();

}

ttscommit;

}

Creating a Reporting Project

Next, create a reporting project in Microsoft Visual Studio. When you create a reporting project, you use the Report Model to create a Reporting Services report.

To create a reporting project

1. Open Microsoft Visual Studio.
2. On the File menu, point to New, and then click Project. The New Project dialog box displays.
3. In the Installed Templates pane, click Microsoft Dynamics AX. In the Templates pane, click Report Model.
4. In the Name box, type SampleRDPReport, and in the Location box, type a location.
5. Click OK.

A reporting project contains a report model where you can add a report to the model.

Binding a Report to a Report Data Provider Class

Now that you have created a reporting project, you are ready to define an auto design report that displays data from the Cust query. The following procedure explains how to create an auto design report that uses the RDP class as the data source.

To create an auto design report

1. In Solution Explorer, right-click the ReportModel node, point to Add and then click Report.
2. In Model Editor, right-click the Report1 node, and then click Rename.
3. Type CustomerReport as the name.
4. Right-click the Datasets node, and then click Add Dataset.
5. In the Properties window, specify the following values.

Property	Value
Data Source	Dynamics AX
Data Source Type	Report Data Provider
Default Layout	Table
Dynamic Filters	True Note This setting is for dynamic parameters on the report. Setting the property to True allows you to filter the report by setting a range on any fields from the data source table.
Name	Customer
Query	Click the ellipsis button (…). A dialog box displays where you can select an RDP class that is defined in the AOT and identify the fields that you want to use. Select the SrsRDPSampleClass class and click Next. In the Select Fields dialog box, keep all the checkboxes selected, and click OK. Note Based on what you select, the Query property value is updated. In this case, the query is SELECT * FROM SrsRDPSampleClass.TmpCust.

1. In Model Editor, select the Customer node and drag it onto the Designs node. An auto design named AutoDesign1 is created for the report.

Note

If you expand the Parameters node you see the parameters that you defined in the data contract class. When you define nested data contract parameters, they are listed under the Parameters node also. Select the SrsRDPSampleClass_DynamicParameter parameter. In the Properties window, the AOT Query property is set to the query specified in the parmQuery method in the RDP class.

1. Select AutoDesign1 and then click the Preview button.
2. Enter a value for Account number and Account statement that returns data and then click the Report tab to preview the report.

Note

You can use * to display all of the account numbers on the report. Account statement is an enumeration and there is no wild card value for enumerations. Check your sample data to determine a valid enumeration value for Account statement. The Select button displays because you set the Dynamic Filters property to True on the dataset. You have the option to click the Select button to specify a range to filter the report and limit the data that displays on the report.

The next steps are to add layout and style templates, deploy, and add the report to a menu item so you can see it in Microsoft Dynamics AX.

How to: Create a Workflow Task AX 2012

A Microsoft Dynamics AX workflow task is a single unit of work that must be performed. A workflow may contain one or more tasks.

The following procedure describes how to create a new workflow task in the AOT.

To create a workflow task

1. In the AOT, expand the Workflow node.
2. Right-click the Tasks node, and then click Add-Ins > Task wizard. The Workflow wizard is displayed. This wizard will help you create a new workflow task.
3. Click Next.
4. Set the following values for the wizard.

Value	Description
Name	The name that will be used for the workflow task.
Workflow document	The class that defines the workflow document for which you are creating a task. Note This setting must match the Document property setting used in the workflow type for the task.
Document preview field group	The initial set of fields displayed in the unified work list. Select a field group from the root table specified in the Workflow document that you selected. The Workflow document value must be set before you can select a field group.
Document menu item	Choose the menu item that points to the main form that displays the document for which you are creating a workflow task.
Document web menu item	Choose the web menu item that points to the Enterprise Portal page that displays the document for which you are creating a workflow task.

1. Specify which types of menu items you want to create. You can create menu items for the Microsoft Dynamics AX client, web menu items for Enterprise Portal, or items for both.
2. Click Next.
3. Define the task outcomes. For each outcome that you want to support, supply a Name for the outcome. The name cannot contain spaces. Specify the Type for the outcome. Choose one of the following types:
   • Complete - Completes the workflow task and continues the workflow forward.
   • Return - Returns the task to the originator for changes and then resubmission back to workflow.
   • RequestChange - Sends the task to a specified user for changes and then resubmission back to workflow.
   • Deny - Completes the task as denied and continues the workflow forward.

Click Add.

Note Each task must have one outcome of type Complete.

1. After you have finished defining the outcomes, click Next. A list of all of the resources that will be created for the workflow task is displayed.
2. Click Finish to create the resources. The wizard will create classes, menu items, web menu items, the task, and a project that contains all of the items.
3. A dialog box will be displayed that indicates the status. Click OK. The project that contains the workflow type resources is displayed.

After a workflow task is created, you can add the workflow task to the Supported Elements node of a workflow type.

How to: Create a Workflow Document Class [AX 2012]

Microsoft Dynamics AX table fields are defined in a query to create workflow conditions. A limitation of a Microsoft Dynamics AX query is that you cannot define calculated fields in the query itself. It is a common scenario to use calculated fields to determine the behavior of a workflow. For example, a dynamic sales total of all records in a table can be used as a workflow condition to determine whether the step should be used. To overcome this query limitation, you must use a workflow document class.

The workflow document class that you create defines table fields for conditions in two ways: the Application Object Tree (AOT) query and parameter methods. The getQueryName method of the WorkflowDocument Class must be overridden to return the name of the query. You can optionally add calculated fields by adding parameter methods with a specific signature on the class.

Before you begin these procedures, you must create a query that specifies the data that will be accessed.

The following procedures show how to create a workflow document class including a parameter method for a calculated field.

Note

If you used the Workflow Wizard to create the workflow type, the workflow document class will have already been created by the wizard.

To create a workflow document class

1. In the AOT, expand the Classes node.

2. Right-click the Classes node, and then select New Class. A class group displays under the Classes node.

3. Right-click the new class, click Rename, and then enter a name for the workflow document class.

4. Expand the new class, select classDeclaration, right-click the class declaration, and then click Edit.

5. Enter the following code in the class declaration.

   X++

   class <MyWorkflowDocumentClassName> extends WorkflowDocument
   {
   }
   

   
   
6. 
   

   Close the Editor window and click Yes to save changes.

   
   
7. 
   

   Right-click the new class, point to Override Method, and then click getQueryName. A method node named getQueryName displays under the workflow document class node and the Editor window opens.
   

   Note
   

   Be sure to select getQueryName as the method to override. The WorkflowDocument.getQuery Method is used only internally to retrieve the actual query based on the string returned by theWorkflowDocument.getQueryName Method.

   
   
8. 
   

   In the Editor window, enter the following code for the query method.
   

   X++

   QueryName getQueryName()
   {
       return querystr(<MyWorkflowDocumentQueryName>);
   }
   

After you create the workflow document class, you can bind it to the workflow type. For more information, see How to: Associate a Workflow Document Class with a Workflow Type.

To add a calculated field to the workflow document class, it must:

• 
  

  Be named parm <name>.

  
  
• 
  

  Define the parameters CompanyId, TableId, and RecId.

  
  
• 
  

  Return an extended data type that will be included in the list of fields for defining conditions or notification messages. The label for the EDT must uniquely identify the value.

To add a calculated field to the workflow document class

1. 
   

   In the workflow document class that you want to add a calculated field to, right-click the class, and then click New Method. A new method node displays under the Classes node.

   
   
2. 
   

   Right-click the new method node, and then click Edit. Enter code that uses the format shown in the following code example.

The following code example shows how to add a calculated field to determine the total credit amount for a journal.

X++

public TotalJournalCreditAmount parmTotalJournalCreditAmount(CompanyId _companyId, TableId _tableId, RecId _recId)
{
    // The calculateAmounts method contains business and validation logic   
    this.calculateAmounts(_companyId, _tableId, _recId);

    return totalJournalCreditAmount;
}

How to: Create a Workflow Category [AX 2012]

When you create a workflow type in Microsoft Dynamics AX, it must be assigned to a workflow category. The workflow category determines whether a workflow type is available in a specific module. If an appropriate workflow category does not already exist, you must create one.

For example, a workflow type for a customer invoice should not be available in the Master planning module. To make the workflow type available only in the Customer module, create a workflow category with the Customer module selected.

The following procedure describes how to create a new workflow category.

To create a workflow category

1. In the AOT, expand the Workflow node.
2. Right-click the Workflow Categories node, and then click New Workflow Category. A new workflow category group displays under the Workflow Categories node.
3. Right-click the new workflow category and then click Properties.
4. In the Properties sheet, set the following properties as required.

Property	Value
Name	The name that is used to reference the workflow category.
Label	The label used for the workflow category in the user interface.
Help Text	The description of the workflow category displayed in the configuration user interface.
Module	The module that the workflow will be available in. The default is Ledger.

After a workflow category is created, you can bind the workflow type to the new category. Typically, this is performed by the Workflow Wizard. The following procedure describes how to manually bind a workflow type to a workflow category.

To bind a workflow type to a workflow category

1. In the AOT, expand the Workflow node, and then expand the Workflow Types node.
2. Right-click the workflow type that you want to bind a workflow category to, and then select Properties.
3. In the Properties sheet, set the Category property to the workflow category created in the previous procedure.

How to: Create a New Module with Workflow [AX 2012]

In Microsoft Dynamics AX, modules are enabled for workflow. However, in some cases, you will need to create a new module that contains workflow. In each module that contains workflow, a Workflows list menu item must be added to the Setup pane. The following procedures are described in this topic:

• Creating a new module enumeration.
• Creating a display menu item for the Workflows list.
• Creating a menu for the new module.
• How to display the new menu in the client.

To Add a Module to the ModuleAxapta Base Enum

1. In the Application Object Tree (AOT), expand the Data Dictionary node, expand Base Enums, right-click ModuleAxapta, and then click New Element. A new enumeration displays under the ModuleAxaptanode.
2. Right-click the new enumeration, and then click Properties.
3. In the Properties sheet, select the Label property, and then enter the label of the new module.

To Create a Display Menu Item for the Workflows List

1. In the AOT, expand the Menu Items node.
2. Right-click the Display node, and then click New Menu Item. A new menu item displays under the Display node.
3. Right-click the new display menu item, and then click Properties.
4. In the Properties sheet, set the following properties.

Property	Value
Name	Set to WorkflowConfigurations<xxx> where <xxx> is replaced by a reference to the name of the new module. For example, you could set this value to WorkflowConfigurationsRecruit for a new module named Recruiting.
Label	Set text or a label that represents the text for the workflows list in the client.
ObjectType	Set to Form.
Object	Set to WorkflowTableListPage.
EnumTypeParameter	Set to ModuleAxapta.
EnumParameter	Set to the enum created in the preceding procedure.

1. In the AOT, right-click the new display menu item, and then click Save.

After the new module enum and display menu item are created, you can add them to the Menus node.

To Create a Menu for a New Module

1. In the AOT, right-click the Menus node, and then click New Menu. A new menu displays under the Menus node.
2. Right-click the new menu, and then click Properties.
3. In the Properties sheet, set the following properties.

Property	Value
Name	Set to a label or name of the new module.
Label	Set to a label that represents the text to display for the new menu in the client.

1. In the AOT, right-click the new menu, point to New, and then click New Submenu. A submenu node displays under menu node created in the previous step.
2. Right-click the new submenu node, and then click Properties.
3. In the Properties sheet, set the following properties.

Property	Value
Name	Set to Setup or another label that represents the text for the Setup pane in the client.
Label	Set to Setup or another label that represents the text for the Setup pane in the client.
NormalImage	Set to 3478. This will display a gears icon for the setup pane.
ImageLocation	Set to EmbeddedResource.

1. In the AOT, right-click the Setup node created in the previous step, point to New, and then click New Menu item. A new menu item displays under the Setup node.
2. Right-click the new menu item, and then click Properties.
3. In the Properties sheet, set the MenuItemName property to the display menu item created in the previous procedure.
4. In the AOT, right-click the new menu item, and then click Save.

After the menu for the new module is created, you must add a reference to the menu in the MainMenu node to display the menu in the client.

To Add a Menu to the Client

1. In the AOT, expand the Menus node, right click MainMenus, point to New, and then click Menu reference. The Select: Menus window is displayed.
2. In the Select: Menus window, select the new module menu that you created in the previous procedure, and drag the menu to the MainMenu node in the AOT.
3. In the AOT, right-click the MainMenu node, and then click Save.

How to: Enable a State Model for a Workflow Document [AX 2012]

Workflow documents in a Microsoft Dynamics AX workflow must implement a state model to represent the state of a workflow, approval, or task for a workflow document in the application. For example, a workflow document in the NotSubmitted state can be changed to the Submitted state when a user clicks the Submit button. This section describes how to enable the state model for a workflow document by using a class or by creating a method on a table.

The following table contains recommended states. However, the needs of your application will determine what states are needed, validation type for state transitions, and how many states are needed. For more information, see Workflow Approval State Transitions post.

For the state of the	Use
Workflow document	NotSubmitted Submitted ChangeRequested Returned Completed

Typically, the workflow state should be persisted in the root table of your workflow document data source. To add workflow state to a table, create an enum in the BaseEnums node of the Application Object Tree (AOT) that contains the workflow states shown in the previous table. The first enum defined should be the NotSubmitted enum, and this will also be the default setting in the table. After the enum is defined, drag the enum to the Fields node of the workflow document data source table.

After a state model is defined, you can enable forms and lists to work with workflow. For more information, see How to: Enable a Form or List for Workflow post.

Note : Workflow state can be implemented in many ways. The following procedure shows one way of performing this task.

To create a state change manager class

1. In the AOT, expand the Classes node.

2. Right-click the Classes node, and then select New Class. A class group displays under the Classes node.

3. Right-click the new class, click Rename, and then enter a name for the class.

4. Right-click the new class and then click New Method. A method node named method1 displays under the Classes node.

5. Right-click method1 and then click Edit. Enter the following code for the started event method.

   X++

   public static void started(RecID _recID)
   {
       <insert method here>
   }

   
   
6. 
   

   Repeat steps 4 and 5 for the remaining states.

Example

The following code is part of the setWorkflowState on the PurchReqTable Table. This method sets the workflow state field in the table and updates the user interface with a user friendly status, and then updates the state in the database.

X++

static void setWorkflowState(RecId _purchReqRecId, PurchReqWorkflowState _purchReqWorkflowState)
{
    // Declare variables.
    PurchReqTable purchReqTable;

    ttsbegin;
 
    // Selects the record to be updated based on the recId and then
    // sets the workflow state. 
    purchReqTable = PurchReqTable::findRecId(_purchReqRecId, true);
    purchReqTable.State = _purchReqWorkflowState;

    // Based on the workflow state, the status in the user interface
    // is updated with a user friendly status.
    switch (_purchReqWorkflowState)
    {
        case PurchReqWorkflowState::Submitted:
            purchReqTable.Status = PurchReqStatus::Submitted;
            break;
        case PurchReqWorkflowState::NotSubmitted:
            purchReqTable.Status = PurchReqStatus::Draft;
            break;
        case PurchReqWorkflowState::Completed:
            purchReqTable.Status = PurchReqStatus::Completed;
            break;
        case PurchReqWorkflowState::Returned:
            purchReqTable.Status = PurchReqStatus::Rejected;
            break;
        case PurchReqWorkflowState::ChangeRequest:
            purchReqTable.Status = PurchReqStatus::ChangeRequested;
            break;
    }
 
    // Commits the state to the database. 
    purchReqTable.update();
 
    ttscommit;
}

How to: Enable a State Model for a Workflow Document [AX 2012]

Workflow documents in a Microsoft Dynamics AX workflow must implement a state model to represent the state of a workflow, approval, or task for a workflow document in the application. For example, a workflow document in the NotSubmitted state can be changed to the Submitted state when a user clicks the Submit button. This section describes how to enable the state model for a workflow document by using a class or by creating a method on a table.

The following table contains recommended states. However, the needs of your application will determine what states are needed, validation type for state transitions, and how many states are needed. For more information, see Workflow Approval State Transitions post.

For the state of the	Use
Workflow document	NotSubmitted Submitted ChangeRequested Returned Completed

Typically, the workflow state should be persisted in the root table of your workflow document data source. To add workflow state to a table, create an enum in the BaseEnums node of the Application Object Tree (AOT) that contains the workflow states shown in the previous table. The first enum defined should be the NotSubmitted enum, and this will also be the default setting in the table. After the enum is defined, drag the enum to the Fields node of the workflow document data source table.

After a state model is defined, you can enable forms and lists to work with workflow. For more information, see How to: Enable a Form or List for Workflow post.

Note : Workflow state can be implemented in many ways. The following procedure shows one way of performing this task.

To create a state change manager class

1. In the AOT, expand the Classes node.

2. Right-click the Classes node, and then select New Class. A class group displays under the Classes node.

3. Right-click the new class, click Rename, and then enter a name for the class.

4. Right-click the new class and then click New Method. A method node named method1 displays under the Classes node.

5. Right-click method1 and then click Edit. Enter the following code for the started event method.

   X++

   public static void started(RecID _recID)
   {
       <insert method here>
   }

   
   
6. 
   

   Repeat steps 4 and 5 for the remaining states.

Example

The following code is part of the setWorkflowState on the PurchReqTable Table. This method sets the workflow state field in the table and updates the user interface with a user friendly status, and then updates the state in the database.

X++

static void setWorkflowState(RecId _purchReqRecId, PurchReqWorkflowState _purchReqWorkflowState)
{
    // Declare variables.
    PurchReqTable purchReqTable;

    ttsbegin;
 
    // Selects the record to be updated based on the recId and then
    // sets the workflow state. 
    purchReqTable = PurchReqTable::findRecId(_purchReqRecId, true);
    purchReqTable.State = _purchReqWorkflowState;

    // Based on the workflow state, the status in the user interface
    // is updated with a user friendly status.
    switch (_purchReqWorkflowState)
    {
        case PurchReqWorkflowState::Submitted:
            purchReqTable.Status = PurchReqStatus::Submitted;
            break;
        case PurchReqWorkflowState::NotSubmitted:
            purchReqTable.Status = PurchReqStatus::Draft;
            break;
        case PurchReqWorkflowState::Completed:
            purchReqTable.Status = PurchReqStatus::Completed;
            break;
        case PurchReqWorkflowState::Returned:
            purchReqTable.Status = PurchReqStatus::Rejected;
            break;
        case PurchReqWorkflowState::ChangeRequest:
            purchReqTable.Status = PurchReqStatus::ChangeRequested;
            break;
    }
 
    // Commits the state to the database. 
    purchReqTable.update();
 
    ttscommit;
}

Workflow Approval State Transitions [AX 2012]

Microsoft Dynamics AX workflow documents that are enabled for workflow approvals typically support at least five workflow states. The current workflow state of a workflow can be maintained in a table field associated with the workflow document. As the state of the document is changed, the state field in the table should be updated. This topic describes workflow approval states.

Workflow State

Workflow state determines what you can do with the workflow document as soon as it is available in the system. Workflow states are defined by developers and must be supported in queries and business logic for operations that are controlled by workflow. Workflow approvals typically use the following workflow states.

 

Workflow state	Use
NotSubmitted	The state of the document before it is submitted to workflow or if the workflow is canceled. This is the state of all documents before a workflow instance is instantiated for the document.
Submitted	The state of the document as soon as the workflow is activated and the document is submitted to workflow. This is a temporary state when the user activates a workflow, but the system has not yet processed the workflow for activation.
PendingApproval	The state of the document as soon as the approval starts and remains in this state until the approval is completed, returned for a change, or rejected.
ChangeRequested	The state of the document if a change is requested or the document is returned.
Approved	The state of the document when the approval is completed.

The following diagram illustrates a typical approval state transition model.

Here are some general guidelines for workflow state:

• Avoid creating your own workflow states unless you have a business justification for doing this.

• Consider refactoring existing approval states so that you can take advantage of the states listed here.

Requirements for Enabling Workflow in an Application Module [AX 2012]

To enable a Microsoft Dynamics AX workflow for a new or existing application module, you must complete a series of required steps and then, depending on application requirements, complete additional steps. This topic describes the required steps to add workflow to your application.

Required Steps

The following steps are necessary for every workflow:

1. Create a state model. For more information about a recommended state model, see Workflow Approval State Transitions and How to: Enable a State Model for a Workflow Document.

2. Add a workflow display menu item. The workflow display menu item is used to access the workflow types for each module. For more information, see How to: Create a New Module with Workflow.

3. Create a workflow category. A workflow category filters workflow types to a single module. If adding a new module, extend the ModuleAxapta Base Enums type. For more information, see How to: Create a Workflow Category.

4. Create a workflow document class to define the workflow document for the workflow. You will create a query, and if needed, add calculated fields to identify the derived fields available for conditions displayed in the workflow configuration tool. For more information, see How to: Create a Workflow Document Class.

5. Enable a form or list for workflow. You must set properties on a form or list to display the workflow button and controls. For more information, see How to: Enable a Form or List for Workflow.

6. Enable documents to be submitted to the workflow. For more information, see How to: Enable Workflow Submission.

7. Create a workflow type. A workflow type defines information about which workflow document to use, tasks, automated tasks, approvals, line item workflows, workflow category, menu items, and event handlers. For more information, see Creating a Workflow Type.

8. Activate the workflow. There are several ways to activate the workflow. For more information, see Activating a Workflow.

9. Define and implement event handlers for the workflow, approvals, tasks, and automated tasks. For more information, see Handling Workflow Events.

10. Implement workflow providers for due date, participant, hierarchy, and queue assignment. For more information, see Workflow Providers.

11. Define and implement approvals, tasks, and automated tasks. For more information, see Creating Workflow Tasks, Automated Tasks, and Approvals.

Optional Steps

1. Create custom workflow providers. For more information, see How to: Create a Custom Workflow Provider.

2. Create event handlers for tasks. For more information, see How to: Create a Workflow Event Handler.

Hint : You can find and follow All mentioned topics related to this post at my blog.

About Workflow Development [AX 2012]

Workflow is defined as the movement of documents or tasks through a work process. In Microsoft Dynamics AX, the focus of workflow is on approval and task-oriented workflows. The developer role in Microsoft Dynamics AX is primarily to add workflow to existing business documents or create new documents that support workflow. This topic describes what the workflow life cycle is and the developer role for a workflow in Microsoft Dynamics AX.

Workflow can be described as structured or unstructured. In Microsoft Dynamics AX, workflow is structured and based on user interaction and system automation of business data. For example, when a purchase requisition (business data) is created it, workflow can be used to verify and approve the data.

Workflow Lifecycle

All workflows follow a basic life cycle as shown in the following illustration.

You design the workflow based on customer requirements. The company administrator configures the workflow, and users run the workflow. This section describes the some of the main development concepts used in the design section of the workflow life cycle in Microsoft Dynamics AX.

Workflow types

The workflow type is a building block that can be used to create customized workflows that enforce business policies. The workflow type is defined in the Application Object Tree (AOT) at design time. The metadata from the workflow type is used by the customer to create a workflow configuration.

Workflow configurations

Workflow configurations are created by application administrators that use the Microsoft Dynamics AX workflow editor. The administrator configures the workflow, workflow elements, and approval steps that control the flow of the business document though the workflow process.

Workflow instances

A workflow instance is created by the workflow runtime when a workflow is activated.

Workflow elements

The elements of a workflow are created by you in the AOT and configured by application administrators. The workflow structure consists of sequences of workflow elements. An element can be a task, automated task, approval, or a sub-workflow.

Approvals are specialized workflow elements that allow for sequencing of multiple steps, which use a fixed set of outcomes. Tasks are generic workflow elements that represent a single unit of work which use custom outcomes defined by the developer. Automated tasks are workflow elements used to invoke X++ code within the application without requiring human intervention.

Work items

Work items are the units of work created by the workflow at runtime. They are the main interface between the end user who participates in a workflow and the workflow runtime. All work items for users who are logged on are surfaced in the Unified Work List and are used to inform a user about work assignments.

Developer Role

You must create the workflow artifacts, dependent workflow artifacts, and business logic to support the workflow. The following sections describe most of the developer artifacts used in a Microsoft Dynamics AX workflow.

Workflow Artifacts

• Workflow type

  • Define the workflow document.

  • Define event handlers for workflow Started, Completed, ConfigDataChanged, and Canceled.

  • Define menu items used for the workflow type like Submit.

  • Define the workflow category.

  • Define required approvals, tasks, and automated tasks.

  • Enable and disable activation conditions.

• Workflow category

  • Define the module that the workflow type is enabled in.

• Approval

  • Define the approval workflow document.

  • Define approval event handlers for Started and Canceled.

  • Define approval menu items such as Document, Resubmit, and Delegate.

  • Enable or disable fixed approval outcomes.

  • Define approval outcome menu items for Action and ActionWeb.

  • Define approval outcome event handler.

  • Define the DocumentPreviewFieldGroup.

• Task

  • Define the task workflow document.

  • Define task event handlers for Started and Canceled.

  • Define task menu items for Document, DocumentWeb, Resubmit, ResubmitWeb, Delegate, and DelegateWeb.

  • Enable or disable task outcomes.

  • Define task outcome menu items for Action and ActionWeb.

  • Define task outcome event handler.

  • Define the DocumentPreviewFieldGroup.

• Automated Task

  • Define the automated task workflow document.

  • Define automated task event handlers for Execution and Canceled.

Dependent Workflow Artifacts

The following workflow artifacts are dependent upon the type of workflow defined in the AOT.

• Workflow Document class - identifies the document query and any calculated fields.

  • Document query - defined in the AOT to expose data that is used for conditions in the configuration user interface.

• SubmitToWorkflow class - displays the Submit to Workflow dialog box in the user interface, receives user comments, activates the workflow, and can update workflow state.

• State model - tracks the state of the document in the workflow process, for example, Submitted, ChangeRequested, or Approved.

• Event handlers for the workflow itself on the workflow type, approval, approval outcomes, automated task, task, and task outcomes.

• Action and display menu items as well as classes which determine the action taken when a menu item is selected in the user interface.

• Custom workflow providers.

• canSubmitToWorkflow method - required on each table enabled for workflow.