Microsoft Dynamics AX 2012 Excel Add-in – Questions and Answers (Business Logic)

Microsoft Dynamics AX 2012

Excel Add-in – Questions and Answers (Business Logic)

 

Purpose: The purpose of this document is to provide answers to frequently asked questions related to Microsoft Dynamics AX 2012 Excel Add-in.

 

Question: How can I execute additional business logic using Microsoft Dynamics AX 2012 Excel Add-in?

 

Answer: Microsoft Dynamics AX 2012 Excel Add-in uses AIF Web Services for publishing the data into Microsoft Dynamics AX 2012. In order to automate certain processes or execute additional business logic you can override updateNow method in appropriate AIF Document class and implement necessary business logic in X++. In this document to illustrate main concepts I will use General journal (LedgerGeneralJournalService) and Customer Payment journal (LedgerCustPaymJournalService) Web Services in Microsoft Dynamics AX 2012.

 

Details

 

Every AIF Web Service has corresponding Document class in AOT, usually these classes are prefixed with Axd. For example, General journal Web Service Document class is AxdLedgerGeneralJournal class and Customer Payment journal Web Service Document class is AxdCustPaymJournal class. Focusing on Business Logic aspect in this investigation we'll take a closer look at Framework classes implementing create and update operations.

 

Classes\AxdBaseCreate\Methods\deserializeDocument

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxdBase\Methods\updateNow

<![if !supportLists]>-          <![endif]>Classes\AxdBaseUpdate\Methods\postProcessDocument

<![if !supportLists]>-          <![endif]>Classes\AxdBaseUpdate\Methods\deserializeDocument

<![if !supportLists]>-          <![endif]>Classes\AxdBaseCreate\Methods\createDocumentList

<![if !supportLists]>-          <![endif]>Classes\AxdBase\Methods\createList

<![if !supportLists]>-          <![endif]>Classes\AifDocumentService\Methods\createList

 

Classes\AxdBaseUpdate\Methods\postProcessDocument

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxdBase\Methods\updateNow

<![if !supportLists]>-          <![endif]>Classes\AxdBaseUpdate\Methods\postProcessDocument

<![if !supportLists]>-          <![endif]>Classes\AxdBaseUpdate\Methods\deserializeDocument

<![if !supportLists]>-          <![endif]>Classes\AxdBaseUpdate\Methods\updateDocumentList

<![if !supportLists]>-          <![endif]>Classes\AxdBase\Methods\updateList

<![if !supportLists]>-          <![endif]>Classes\AifDocumentService\Methods\updateList

…

 

updateNow method in Document class will be executed as a last step (post-processing) after AIF message processing which allows you to execute additional business logic

 

For example, after General journal will be created or updated via General journal Web Service certain fields such as Journal balance, etc will be updated

 

Classes\AxdLedgerGeneralJournal\Methods\updateNow

 

For comparison in Rich Client when you post General journal Journal balance update is triggered from Form in "Validate" (and "Post") button clicked method

 

Forms\LedgerJournalTransDaily\Designs\DesignList\ButtonCheckJournal\Methods\clicked

 

Another example is Customer Payment journal when after its creation or update in certain scenarios it may be necessary to generate Settlements against Customer invoices

 

Classes\AxdCustPaymJournal\Methods\updateNow

 

Typical requirement for automation is when you need to automatically post General journal after its successful creation. Please see below how you can implement this requirement in Microsoft Dynamics AX 2012

 

LedgerJournalPost::postJournal(LedgerJournalTable, false);

 

Classes\AxdLedgerGeneralJournal\Methods\updateNow

 

If you face with this requirement I'd also recommend introducing dedicated parameter in UI to control whether it's required or not to automatically post General journal when General journal AIF Web Service is invoked

 

Once you change necessary Document class please generate CIL because all AIF Web Services related code in Microsoft Dynamics AX 2012 is executed in CIL on the server

 

Please also note that if you use Tables (Add Tables) in Microsoft Dynamics AX 2012 Excel Add-in the system will use Generic Document Web Service at the back-end

 

Version: Microsoft Dynamics AX 2012 R2

 

Tags: Dynamics ERP, Dynamics AX 2012, Excel, Dynamics AX 2012 Excel Add-in, Data Import, Data Conversion, Data Migration, Application Integration Framework, Question, Answer, Business Logic.

 

Note: This document is intended for information purposes only, presented as it is with no warranties from the author. This document may be updated with more content to better outline the issues and describe the solutions.

 

Author: Alex Anikiev, PhD, MCP

Microsoft Dynamics AX 2012 Excel Add-in – Questions and Answers (Validation Logic)

Microsoft Dynamics AX 2012

Excel Add-in – Questions and Answers (Validation Logic)

 

Purpose: The purpose of this document is to provide answers to frequently asked questions related to Microsoft Dynamics AX 2012 Excel Add-in.

 

Question: How does Microsoft Dynamics AX 2012 Excel Add-in implement Validation Logic?

 

Answer: The way the system implements Validation logic in Excel Add-in varies depending on AIF proxy classes implementation for particular business entities. In this document to illustrate main concepts I will use General journal (LedgerJournalTrans) business entity in Microsoft Dynamics AX 2012. Also some special controls for interactive validation are provided in Excel Add-in for certain types of information, for example, financial dimensions combinations.

 

Details

 

LedgerJournalTrans Table in Microsoft Dynamics AX 2012 has corresponding AxLedgerJournalTrans AIF Proxy class. All AIF Proxy classes extend AxInternalBase class. AxInternalBase class in its turn implements some core methods related to data manipulation. One of core methods in AxInternalBase class is doSave method. Focusing on Validation logic in this investigation we'll take a closer look at validateFields and validateWrite methods where Validation logic is usually implemented.

 

General journal

 

Rich Client

 

Out-of-the-box in Rich Client on a Form when you change the value for certain field and move the focus to another field the system does auto-save of record and at this time the validation is performed

 

For example, if Currency value is changed on General journal line the system may throw validation error

 

In this particular case X++ validation logic was executed and as the result the user will see the following error

 

Call stack:

<![if !supportLists]>-          <![endif]>Classes\LedgerJournalEngine\currencyModified

<![if !supportLists]>-          <![endif]>Forms\LedgerJournalTrandDaily\Data Sources\LedgerJournalTrans\Fields\CurrencyCode\Methods\modified

 

In some cases validation errors may be caused by data model itself and not X++ validation logic

 

"The currency ALX does not exist" was caused by Relation between Currency and LedgerJournalTrans Tables

 

Tables\LedgerJournalTrans\Relations\Currency

 

X++ validation logic related to LedgerJournalTrans Table can be found in validateField and validateWrite method. validateField is executed when any field is changed and validateWrite method is executed for the entire record upon save 

 

Tables\LedgerJournalTrans\Methods\validateField

 

Tables\LedgerJournalTrans\Methods\validateWrite (validateWrite_Server)

 

Call Stack:

<![if !supportLists]>-          <![endif]>Tables\LedgerJournalTrans\ Methods\validateWrite

<![if !supportLists]>-          <![endif]>Forms\LedgerJournalTransDaily\Data Sources\LedgerJournalTrans\Methods\validateWrite

<![if !supportLists]>-          <![endif]>Forms\LedgerJournalTransDaily\Data Sources\LedgerJournalTrans\ Methods\leaveRecord

 

The principal difference between Rich Client and Excel Add-in is that in Rich Client some code is executed on the client which allows for interactive data validation (stateful behavior) and Excel Add-in will have to go through formal AIF interface every time the data is published into Microsoft Dynamics AX 2012 (stateless behavior). Please note that when you deal with Form in Rich Client you already deal with predefined dataset as opposite to Excel Add-in where you have to define your dataset first. That's why in Rich Client it's possible to execute Validation logic from Form interactively.

 

Excel Add-in

 

AxLedgerJournalTrans AIF Proxy class implements Validation logic in validateField and validateWrite methods

 

Classes\AxLedgerJournalTrans\Methods\validateField

 

Classes\AxLedgerJournalTrans\Methods\validateWrite

 

Please note that validateField and validateWrite methods in AxLedgerJournalTrans AIF Proxy class will eventually trigger validateField and validateWrite methods in LedgerJournalTrans Table

 

Currently out-of-the-box in Microsoft Dynamics AX 2012 R2 (September CTP) LedgerGeneralJournalService Web Service and LedgerJournalTrans Table can't be used due to error shown below

 

General journal – Add Data (LedgerGeneralJournalService)

 

General journal – Add Tables (LedgerJournalTrans)

 

That's why for the sake of General journal Validation logic demo I'll use Microsoft Dynamics AX 2012 FPK

 

Example of X++ validation logic error

 

Before publishing

 

After publishing

 

Example of data model validation logic error

 

Before publishing

 

After publishing

 

Excel Add-in also provides special controls for interactive validation for certain types of information. For example, financial dimension combination may be validated using "Select dimension attribute values" control

 

 

 

Please note that Segmented control in Rich Client shows different value lookup (Ledger account, Vendor, Customer, etc} depending of Account type = {Ledger, Vendor, Customer, etc}, however corresponding "Select dimension attribute values" control in Excel Add-in is only tailored for Ledger accounts 

 

Versions: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 FPK

 

Tags: Dynamics ERP, Dynamics AX 2012, Excel, Dynamics AX 2012 Excel Add-in, Data Import, Data Conversion, Data Migration, Application Integration Framework, Question, Answer, Validation Logic.

 

Note: This document is intended for information purposes only, presented as it is with no warranties from the author. This document may be updated with more content to better outline the issues and describe the solutions.

 

Author: Alex Anikiev, PhD, MCP

Microsoft Dynamics AX 2012 Excel Add-in – Questions and Answers (Related Records)

Microsoft Dynamics AX 2012

Excel Add-in – Questions and Answers (Related Records)

 

Purpose: The purpose of this document is to provide answers to frequently asked questions related to Microsoft Dynamics AX 2012 Excel Add-in.

 

Question: How does Microsoft Dynamics AX 2012 Excel Add-in deal with Related Records?

 

Answer: The way the system implements Related records logic in Excel Add-in varies depending on AIF proxy classes implementation for particular business entities. In this document to illustrate main concepts I will use Sales order (SalesTable/SalesLine) and Purchase order (PurchTable/PurchLine) business entities in Microsoft Dynamics AX 2012.

 

Details

 

SalesTable/SalesLine and PurchTable/PurchLine Tables in Microsoft Dynamics AX 2012 have corresponding AxSalesTable/AxSalesLine and AxPurchTable/AxPurchLine AIF Proxy classes. All AIF Proxy classes extend AxInternalBase class. AxInternalBase class in its turn implements some core methods related to data manipulation. One of core methods in AxInternalBase class is doSave method. Focusing on Related records in this investigation we'll take a closer look at createOrUpdateRelatedRecords method where Related records logic is usually implemented.

 

 

Sales order – Sales line and Purchase order – Purchase line

 

Data Model

 

<![if !vml]><![endif]>

 

In Microsoft Dynamics AX 2012 you can add Miscellaneous charges to Sales order/line and Purchase order/line. MarkupTrans Table contains all types of Miscellaneous charges transactions and references to the original document by TableID/RecID (TransTableID/TransRecID).

 

Rich Client

 

Out-of-the-box in Rich Client once you change Charges group on Sales order MarkupTrans record(s) may be automatically populated based on predefined rules (Automatic charges)

 

 

This is triggered in update method of SalesTableType class

 

Classes\SalesTableType\Methods\update

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\Markup\insertMarkupTrans

<![if !supportLists]>-          <![endif]>Tables\SalesTable\Methods\createMarkupTrans

<![if !supportLists]>-          <![endif]>Classes\SalesTableType\Methods\update

<![if !supportLists]>-          <![endif]>Tables\SalesTable\Methods\update

<![if !supportLists]>-          <![endif]>Forms\SalesTable\Data Sources\SalesTable\Methods\update

 

The principal difference between Rich Client and Excel Add-in is that in Rich Client some code is executed on the client which allows for interactive data manipulation (stateful behavior) and Excel Add-in will have to go through formal AIF interface every time the data is published into Microsoft Dynamics AX 2012 (stateless behavior). Please note that when you deal with Form in Rich Client you already deal with predefined dataset as opposite to Excel Add-in where you have to define your dataset first. That's why in Rich Client it's possible to trigger Related records logic from Form interactively. For example, when the record is changed on Form Data source update method on respective Data source (and update methods on Table) will be executed.

 

Excel Add-in

 

Sales line – Miscellaneous charges

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxSalesLine\createOrUpdateRelatedRecords

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\doSave

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\save

…

 

Please note that as soon as Excel Add-in uses formal AIF interface Related records will be populated when you publish data into Microsoft Dynamics AX 2012.

 

Purchase order – Purchase line

 

Rich Client

 

Similarly once you change Charges group on Purchase order MarkupTrans record(s) may be automatically populated based on predefined rules (Automatic charges)

 

 

This is triggered in update method of PurchTableType class

 

Classes\PurchTableType\Methods\update

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\Markup\insertMarkupTrans

<![if !supportLists]>-          <![endif]>Tables\PurchTable\Methods\createMarkupTrans

<![if !supportLists]>-          <![endif]>Classes\PurchTableType\Methods\update

<![if !supportLists]>-          <![endif]>Tables\PurchTable\Methods\update

<![if !supportLists]>-          <![endif]>Forms\PurchTable\Data Sources\PurchTable\Methods\update

 

Excel Add-in

 

Purchase line – Miscellaneous charges

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxPurchLine\createOrUpdateRelatedRecords

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\doSave

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\save

…

 

Please note that Related records logic will be executed after Defaulting logic when data is published into Microsoft Dynamics AX 2012 through AIF interface.

 

Version: Microsoft Dynamics AX 2012 R2

 

Tags: Dynamics ERP, Dynamics AX 2012, Excel, Dynamics AX 2012 Excel Add-in, Data Import, Data Conversion, Data Migration, Application Integration Framework, Question, Answer, Related Records.

 

Note: This document is intended for information purposes only, presented as it is with no warranties from the author. This document may be updated with more content to better outline the issues and describe the solutions.

 

Author: Alex Anikiev, PhD, MCP

Microsoft Dynamics AX 2012 Excel Add-in – Questions and Answers (Depending Fields)

Microsoft Dynamics AX 2012

Excel Add-in – Questions and Answers (Depending Fields)

 

Purpose: The purpose of this document is to provide answers to frequently asked questions related to Microsoft Dynamics AX 2012 Excel Add-in.

 

Question: How does Microsoft Dynamics AX 2012 Excel Add-in deal with Dependent fields?

 

Answer: The way the system implements Depending fields logic in Excel Add-in varies depending on AIF proxy classes implementation for particular business entities. In this document to illustrate main concepts I will use Sales order (SalesTable/SalesLine), Purchase order (PurchTable/PurchLine) and Free Text Invoice (CustInvoiceTable/CustInvoiceLine) business entities in Microsoft Dynamics AX 2012.

 

Details

 

SalesTable/SalesLine, PurchTable/PurchLine and CustInvoiceTable/CustInvoiceLine Tables in Microsoft Dynamics AX 2012 have corresponding AxSalesTable/AxSalesLine, AxPurchTable/AxPurchLine and AxCustInvoiceTable/AxCustInvoiceLine AIF Proxy classes. All AIF Proxy classes extend AxInternalBase class. AxInternalBase class in its turn implements some core methods related to data manipulation.

One of core methods in AxInternalBase class is save method. Focusing on Dependent fields in this investigation we'll take a closer look at valueMapDependentFields method where Dependent fields logic is usually implemented.

 

 

Sales order – Sales line and Purchase order – Purchase line

 

Data Model

 

<![if !vml]><![endif]>

 

In Microsoft Dynamics AX 2012 the combination of inventory dimensions is represented by InventDimId field which references to InventDim Table. Thus SalesLine and PurchLine Tables have InventDimId field which is the foreign key pointing to InventDim Table.

 

Rich Client

 

Out-of-the-box in Rich Client once you save Sales order line InventDimId field is populated automatically

 

 

For Sales order line this is triggered in write method of Form Data Source

 

Forms\SalesTable\Data Sources\SalesLine\Methods\write

 

Similarly once you save Purchase order line InventDimId field is populated automatically

 

 

For Purchase order line this is triggered in write method of Form Data Source

 

Forms\PurchTable\Data Sources\PurchLine\Methods\write

 

The principal difference between Rich Client and Excel Add-in is that in Rich Client some code is executed on the client which allows for interactive data manipulation (stateful behavior) and Excel Add-in will have to go through formal AIF interface every time the data is published into Microsoft Dynamics AX 2012 (stateless behavior). Please note that when you deal with Form in Rich Client you already deal with predefined dataset as opposite to Excel Add-in where you have to define your dataset first. That's why in Rich Client it's possible to trigger Dependent fields logic from Form interactively. For example, when the record is saved on Form Data source write method on respective Data source (and insert or update methods on Table) will be executed.

 

Excel Add-in

 

Sales line – Inventory dimensions

 

Purchase line – Inventory dimensions

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxSalesLine\valueMapDependingFields (Classes\AxPurchLine\valueMapDependingFields)

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\save

…

 

Please note that as soon as Excel Add-in uses formal AIF interface InventDimId field on corresponding Table will be populated when you publish data into Microsoft Dynamics AX 2012.

 

Free text Invoice – Free text Invoice line

 

Data Model

 

<![if !vml]><![endif]>

 

In Microsoft Dynamics AX 2012 State is dependent on Country. Thus for CustInvoiceLine Table which has both OrigCountryRegionId and OrigState fields the system can assign State only if it belongs to specified Country.

 

Rich Client

 

Out-of-the-box in Rich Client once you specify Country on Free Text invoice line the system will provide lookup for State with the list of States which belong to selected Country

 

 

State lookup behavior is dictated by Table Relationship between CustInvoiceLine and LogisticsAddressState Tables

 

Please note that if you try to key in State without Country specified you will see the following warning

 

This means that in order to select State you have to specify Country

 

Excel Add-in

 

Free Text invoice line – Country/State

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxCustInvoiceLine\valueMapDependingFields

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\save

…

 

Please note that Dependent fields logic will be executed before doSave method of AxInternalBase class with all AIF proxy classes processing logic. In this particular case Country has to be specified in order for the system to accept State specified. Both values will have to be specified for successful publishing of Origin information (Foreign trade) into Microsoft Dynamics AX 2012.

 

Version: Microsoft Dynamics AX 2012 R2

 

Tags: Dynamics ERP, Dynamics AX 2012, Excel, Dynamics AX 2012 Excel Add-in, Data Import, Data Conversion, Data Migration, Application Integration Framework, Question, Answer, Dependent Fields.

 

Note: This document is intended for information purposes only, presented as it is with no warranties from the author. This document may be updated with more content to better outline the issues and describe the solutions.

 

Author: Alex Anikiev, PhD, MCP

Microsoft Dynamics AX 2012 Excel Add-in – Questions and Answers (Defaulting Logic)

Microsoft Dynamics AX 2012

Excel Add-in – Questions and Answers (Defaulting Logic)

 

Purpose: The purpose of this document is to provide answers to frequently asked questions related to Microsoft Dynamics AX 2012 Excel Add-in.

 

Question: How does Microsoft Dynamics AX 2012 Excel Add-in implement defaulting logic?

 

Answer: The way the system implements defaulting logic in Excel Add-in varies depending on AIF proxy classes implementation for particular business entities. In this document to illustrate main concepts I will use General journal (LedgerJournalTable) - Description and Sales order (SalesTable) - Pool business entities fields in Microsoft Dynamics AX 2012.

 

Details

 

LedgerJournalTable and SalesTable Tables in Microsoft Dynamics AX 2012 have corresponding AxLedgerJournalTable and AxSalesTable AIF Proxy classes. All AIF Proxy classes extend AxInternalBase class. AxInternalBase class in its turn implements some core methods related to data manipulation.

One of core methods in AxInternalBase class is doSave method. Focusing on Defaulting Logic in this investigation we'll take a closer look at setTableFields method where the assignment of default values for fields usually happens.  

 

General journal – Description

 

Rich Client

 

Out-of-the-box in Rich Client once you specify Journal name on General journal header Description is populated from Journal name automatically

 

 

This is triggered in modified method of Form Data Source

 

Forms\LedgerJournalTable\Data Sources\LedgerJournalTable\Fields\JournalName\Methods\modified

 

Here's how Description is defined for Journal name

 

 

The principal difference between Rich Client and Excel Add-in is that in Rich Client some code is executed on the client which allows for interactive data manipulation (stateful behavior) and Excel Add-in will have to go through formal AIF interface every time the data is published into Microsoft Dynamics AX 2012 (stateless behavior). Please note that when you deal with Form in Rich Client you already deal with predefined dataset as opposite to Excel Add-in where you have to define your dataset first. That's why in Rich Client it's possible to trigger defaulting logic from Form interactively. For example, when new record is created on Form Data source initValue method on respective Data source (and Table) will be executed, or when field value is modified on the Form the system will execute modified method on Data source field (and modifiedField method on Table).

 

Excel Add-in

 

If you explicitly provide the value of Description before publishing data in Excel Add-in the system will take this value into account. By other words explicitly provided value overrides default value from Journal name 

 

Before publishing

 

After publishing

 

What if I don't specify Description?

 

If you don't provide a value of Description before publishing data in Excel Add-in it will still be populated from Journal name. Please note that you will see populated value of Description in Excel Add-in only after successful publishing 

 

Before publishing

 

After publishing

 

In Microsoft Dynamics AX 2012 LedgerJournalTableType class represents Ledger journal business entity of different types. LedgerJournalTableType class is equipped with number of methods in order to populate default values for certain fields including Description (LedgerJournalTable.Name)

 

Field name	Method name
JournalNum	defaultJournalNum
Name	defaultName
NumberSequenceId	defaultNumberSequenceId
JournalType	defaultJournalType
PaymentGenerated_IT	defaultPaymentGenerated_IT
OffsetAccount	defaultOffsetAccount
PostedDateTime	defaultPostedDateTime
OffsetAccountType	defaultOffsetAccountType
GroupBlockId	defaultGroupBlockId
Dimension	defaultDimension
CurrencyCode	defaultCurrencyCode
FixedExchRate	defaultFixedExchRate
DetailSummaryPosting	defaultDetailSummaryPosting
DocumentNum	defaultDocumentNum
ExchRateSecondary	defaultExchRateSecondary
ExchRate	defaultExchRate
FixedOffsetAccount	defaultFixedOffsetAccount
RemoveLineAfterPosting	defaultRemoveLineAfterPosting
CurrentOperationsTax	defaultCurrentOperationsTax
LedgerJournalInclTax	defaultLedgerJournalInclTax
BankRemittanceType	defaultBankRemittanceType
CustVendNegInstProtestProcess	defaultCustVendNegInstProtestProcess
VoucherAllocatedAtPosting	defaultVoucherAllocatedAtPosting
LinesLimitBeforeDistribution	defaultLinesLimitBeforeDistribution
WorkflowApprovalStatus	defaultWorkflowApprovalStatus

 

Default value of Description is populated in defaultName method

 

Classes\LedgerJournalTableType\defaultName

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\LedgerJournalTableType\defaultName

<![if !supportLists]>-          <![endif]>Classes\LedgerJournalTableType\defaultRow

<![if !supportLists]>-          <![endif]>Classes\AxLedgerJournalTable\defaultRow

<![if !supportLists]>-          <![endif]>Classes\AxLedgerJournalTable\setTableFields

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\doSave

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\save

<![if !supportLists]>-          <![endif]>…

 

Please note that there's also defaulting logic related to Description in insert method in LedgerJournalTable Table which covers other functional scenarios

 

Tables\LedgerJournalTable\Methods\insert

  

Sales order – Pool

 

Rich Client

 

Out-of-the-box in Rich Client once you create Sales order header on Create Sales order form the system will populate Sales Pool ID right away

 

 

Please note that Pool is populated based on Default Pool from Parameters even before particular Customer account is selected

 

 

This is triggered from Form Data source initValue method which will eventually call initValue method on SalesTableType class

 

Once Customer account is selected the system will populate Pool based on Customer settings

 

 

This is triggered from Form Data source modified method which will eventually call modifiedField method on SalesTableType class

 

 

Excel Add-in

 

If you explicitly provide the value of Pool before publishing data in Excel Add-in the system will take this value into account. By other words explicitly provided value overrides default value from Customer (or Parameters)

 

Before publishing

 

After publishing

 

What if I don't specify Pool?

 

If you don't provide a value of Pool before publishing data in Excel Add-in it will still be populated from Customer (or Parameters). Please note that you will see populated value of Pool in Excel Add-in only after successful publishing 

 

Before publishing

 

After publishing

 

In Microsoft Dynamics AX 2012 SalesTableType class represents Sales order business entity of different types. SalesTableType class is equipped with number of methods in order to set values for certain fields including Pool (SalesTable.SalesPoolId)

 

 

Call Stack:

<![if !supportLists]>-          <![endif]>Classes\AxSalesTable\setSalesPoolId

<![if !supportLists]>-          <![endif]>Classes\AxSalesTable\setTableFields

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\doSave

<![if !supportLists]>-          <![endif]>Classes\AxInternalBase\save

…

 

Please note that what was done in 2 steps in Rich Client (Default Pool populated from Parameters and then Pool populated from Customer) on Create Sales order form is executed as 1 step in Excel Add-in when the data is published through AIF interface.

 

Version: Microsoft Dynamics AX 2012 R2

 

Tags: Dynamics ERP, Dynamics AX 2012, Excel, Dynamics AX 2012 Excel Add-in, Data Import, Data Conversion, Data Migration, Application Integration Framework, Question, Answer, Defaulting Logic.

 

Note: This document is intended for information purposes only, presented as it is with no warranties from the author. This document may be updated with more content to better outline the issues and describe the solutions.

 

Author: Alex Anikiev, PhD, MCP