Monday, October 22, 2012

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

Sunday, October 21, 2012

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

Saturday, October 20, 2012

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