Uninstall Microsoft Dynamics AX

This topic explains how to uninstall Microsoft Dynamics AX by using Add or Remove Programs on the Control Panel.

Databases, log files, and application files must be removed manually. Information about how to manually remove components is also included in this topic.

Uninstall components by using Add or Remove Programs

Use this procedure to remove Microsoft Dynamics AX components.

1. Open Add or Remove Programs. (Start > All Programs > Control Panel > Add or Remove Programs).
2. Select the component that you want to remove, and then click Remove. The components that are listed in the following table can be removed.

Option	Removes
Microsoft Dynamics AX Components	Selecting this option removes the following components: o Client o Role Centers and the Enterprise Portal framework o Workflow o Reporting extensions o Debugger o Enterprise Portal developer tools o Reporting tools o .NET Business Connector o AIF Web services o BizTalk adapter o Synchronization proxy for Microsoft Office Project o Synchronization service for Microsoft Office Project This option removes all components that are installed on the local computer. You cannot select to remove individual components.
Microsoft Dynamics AX Client Help Files	Select this option to remove all Help files in all installed languages. You should not remove Help files unless the client is also being removed.
Microsoft Dynamics AX Object Server (instance name)	Select this option to remove a specific Application Object Server (AOS) instance. Before you remove an AOS instance, use the Microsoft Dynamics AX Configuration utility to point all clients to a valid AOS instance, or update the shared configuration file. When you remove an AOS instance, it is not automatically removed from the list of batch and load balancing servers. After you uninstall an AOS instance, you must manually delete it by using the Server configuration form or the Cluster configuration form.

3. A message box asks you to confirm that you want to uninstall. To proceed, click Yes.

Remove remaining components manually

If you choose to remove an entire installation, some components remain after Add or Remove Programs is finished. The following table provides more information about removing components manually.

To remove this	Do this
Application files	Delete the application file directory from the location that you installed it to.
Database and log files	Use database server administration tools to delete the database and log files.
Role Centers and the Enterprise Portal framework	Delete Web sites by using SharePoint Central Administration.
Reporting extensions	· Delete SQL Server Reporting Services objects, such as data sources, reports, and report models by using Reporting Services. · Delete the contents of the Microsoft Dynamics AX report folder.
Analysis extensions	Delete SQL Server Analysis Services objects, such as databases, cubes, and models by using Analysis Services.

Create and Post inventory journal by code : Dynamics AX

        InventJournalTable              inventJournalTable;
        InventJournalTrans              inventJournalTrans;

        InventJournalNameId             inventJournalName;
        InventDim                            inventDim;
        JournalCheckPost               journalCheckPost;
       

//Below code creates journal header       

        inventJournalTable.clear();

        inventJournalName =  InventJournalName::standardJournalName(InventJournalType::Movement);
        inventJournalTable.initFromInventJournalName(InventJournalName::find(inventJournalName ));

        inventJournalTable.insert();

       

//Below code creates journal lines

        inventJournalTrans.clear();

        inventJournalTrans.initFromInventJournalTable(inventJournalTable);

        inventJournalTrans.TransDate = systemDateGet();

        inventJournalTrans.ItemId = "MDJ0001";

        inventJournalTrans.initFromInventTable(InventTable::find("MDJ0001"));

        inventJournalTrans.Qty = 2500;

        inventDim.InventSiteId  = '12';

        inventDim.InventLocationId = '1201';

        inventDim.wMSLocationId = 'BULK-001';

        inventJournalTrans.InventDimId = inventDim::findOrCreate(inventDim).inventDimId;

        inventJournalTrans.insert();

       

//The below code posts the journal
        journalCheckPost = InventJournalCheckPost::newPostJournal(inventJournalTable);
        journalCheckPost.run();

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.

Description of the main processing steps that are performed by the Inventory Close and the Inventory Recalculation in Dynamics AX

When you run the Inventory Close routine or the Inventory Recalculation routine in Microsoft Dynamics AX, Microsoft Dynamics AX performs a sequence of steps in their processing.

Steps that are performed by the Inventory Close routine

When you run the Close routine, Microsoft Dynamics AX performs the following steps:

1. Check whether any Recalculations were run after the date that you choose for your Close. Microsoft Dynamics AX will cancel any of those later Recalculations before the Close can start.
2. Put all the items that are to be processed into a queue. These items are stored in the InventCostList table.
   Note While a Close or Recalculation is processing, you can click Calculation/Calculation List from the Close & adjustment form to view the data in the InventCostList table. This shows which items are still to be processed by the Close or Recalculation process.
3. Process each item from that queue sequentially. Microsoft Dynamics AX performs the following for each item:
   1. Settle individual receipts and issues against one another for the item according to the Inventory Model Group such as FIFO, Weighted Average.
      • Make any required cost adjustments to the issue that was settled based on the cost of the receipt(s) against which the issue was settled.
      • Update the inventory transactions to show the settlement and cost adjustment data.
      • Write the settlement data into the Inventory Settlement table. The data will include records that show explicitly which Receipt(s) were settled to each Issue in addition to any cost adjustment that is made to the Issue that is settled.
   2. As soon as all possible transactions are processed for that item, Microsoft Dynamics AX looks for any transactions that are fully settled, and then update those transactions to "Closed." For more information, see the "What fields show that an inventory transaction is closed" section.
4. As soon as all the items are processed, the settlement records that were created are read and sorted by General Ledger Account. Then, Microsoft Dynamics AX summarizes all the cost adjustments that were made, and a General Ledger Journal is created and posted.
5. If you select the Run recalculation after closing check box in the Close dialog box, a Recalculation will be run for all items up to today's date.

Steps that are performed by the Inventory Recalculation routine

The Inventory Recalculation routine does a similar job to the Inventory Close routine. However, there are a few differences. When you run the Recalculation routine, Microsoft Dynamics AX performs the following steps:

1. Check whether any Recalculations were run after the date that you choose to run your Recalculation up to. Microsoft Dynamics AX will cancel any of those later Recalculations found before your Recalculation routine can start.
   Notes
   • In the Select dialog box, you can select item(s) for which you want to run the Recalculation, unlike the Close routine that always processes all items.
   • While a Recalculation or Close is processing, you can click Calculation/Calculation List from the Close & adjustment form to view the data in the InventCostList table. This shows which items are still to be processed by that Close or Recalculation.
2. Put all the items that are to be processed into a queue, and then store the queue in the InventCostList table.
3. Process each item from that queue sequentially. Microsoft Dynamics AX performs the following for each item:
   • Make a "virtual" settlement between individual receipts and issues for the item according to the Inventory Model Group such as FIFO, Weighted Average. This is a "virtual" settlement because it is occurs in the Recalculation’s calculations. However, the detailed settlement data that shows the explicit matching of each issue to the various receipts is not stored in the InventSettlement table. The only data that is stored is the cost adjustment that is made to the issue.
     • Make any required cost adjustments to the issue that was settled based on the cost of the receipt(s) against which the issue was settled.
     • Write a single settlement record for any cost adjustment that is made for that Issue into the Inventory Settlement table.
4. As soon as all the items are processed, the cost adjustment settlement records that were created are read, sorted by General Ledger Account, and summarized and posted in a General Ledger Journal.

What fields show that an inventory transaction is closed

To show that an inventory transaction is "closed", Microsoft Dynamics AX performs the following:

1. When the Inventory Close routine has fully settled the Quantity and Financial Cost of a specific inventory transaction, Microsoft Dynamics AX updates the individual inventory transaction to show that the transaction is "closed."
2. For a transaction to be closed, it must meet the following criteria:
   • The "Quantity" must match the "Quantity Settled."
   • The sum of "Cost Amount Posted" plus "Cost Amount Adjustment" must match the "Cost Amount Settled."
3. When those conditions are met, then the Close program will do the following:
   • Set the field "Value Open" from "Yes" to "No."
   • Store the date of the close in the field "Date Closed."
   This means that the individual inventory transaction is "closed."

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.

5. 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.
6. Click Next.
7. 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.

8. 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.
9. 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.
10. 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;
}