Dynamics AX Inventory cube now present in AX 2012 R2

It was recently brought to my attention that Microsoft Dynamics AX finally ships with an inventory value cube out of the box in version 2012 R2. You can find details on the measures available in the cube here, which even includes some KPI's for inventory turns and other indicators. I'm looking forward to cracking this open and comparing it to the home grown inventory cube I built on AX 2009. The primary issue is that you can't simply look at inventtrans records because those statuses are updated over time as postings occur.

Other cubes added in AX 2012 R2 include Budget control, Budget plan (my team worked on this), Profit tax, and Retail. 

AX 2012 Cubes	AX 2012 R2 Cubes
Accounts payable cube (VendCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Accounts payable cube (VendCube) for Microsoft Dynamics AX 2012 R2
Accounts receivable cube (CustCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Accounts receivable cube (CustCube) for Microsoft Dynamics AX 2012 R2
	Budget control cube (BudgetControlCube) for Microsoft Dynamics AX 2012 R2
	Budget plan cube (BudgetPlanCube) for Microsoft Dynamics AX 2012 R2
Environmental sustainability cube (EMSCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Environmental sustainability cube (EMSCube) for Microsoft Dynamics AX 2012 R2
Expense management cube (TrvCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Expense management cube (TrvCube) for Microsoft Dynamics AX 2012 R2
General ledger cube (LedgerCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	General ledger cube (LedgerCube) for Microsoft Dynamics AX 2012 R2
	Invent value cube (InventValueCube) for Microsoft Dynamics AX 2012 R2
Production cube (ProdCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Production cube (ProdCube) for Microsoft Dynamics AX 2012 R2
	Profit tax totals cube (RTax25OLAP) for Microsoft Dynamics AX 2012 R2
Project accounting cube (ProjCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Project accounting cube (ProjCube) for Microsoft Dynamics AX 2012 R2
Purchase cube (PurchCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Purchase cube (PurchCube) for Microsoft Dynamics AX 2012 R2
	Retail cube (RetailCube) for Microsoft Dynamics AX 2012 R2
Customer relationship management cube (smmCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Sales and marketing cube (smmSalesMarketingCube) for Microsoft Dynamics AX 2012 R2
Sales cube (SalesCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Sales cube (SalesCube) for Microsoft Dynamics AX 2012 R2
Workflow cube (WorkflowCube) for Microsoft Dynamics AX 2012 and Microsoft Dynamics AX 2012 Feature Pack	Workflow cube (WorkflowCube) for Microsoft Dynamics AX 2012 R2

Slow Inventory Reports

A user over on the AXUG Community recently posted a question about poor performance on the standard AX Inventory reports, specifically Physical Inventory by Dimension. It turns out the fix ended up being to clear the records in two tables in the database that are used only for building this report. Normally the records are created, the report run, and then the records are deleted. However if the process is cancelled the records can be left behind. Multiple users reported the same issue.

If you are having this issue or even minor performance issues with these reports, look into deleting all of the records in the InventSumDateTable and InventSumDateTrans tables via SQL.

If you haven't joined the AXUG Community forum yet go check it out. It's a great free resource for users.

Customs integration with Dynamics AX for EDITrade and CANData

I just wanted to give a quick update on what I've been working on recently. We import product into both the US and to Canada, so we have a need to supply data to both US and Canadian customs.
There are two companies we are working with on this: EDITrade from Descartes for US Customs and CANData Systems for Canadian customs.

I know everyone is gearing up for Convergence 2013, but I'll be back here in Seattle working away. I'd be interested in knowing if anyone finds any other companies that have integrated EDITrade or CANData with Dynamics AX.

Ultimately I plan on providing more details on our integration and some examples.

Costing items multiple different ways per item in Dynamics AX 2009

Background

In AX 2009 inventory costing is controlled by the Dimensions group assigned to an Item when using the weighted avg costing method.

Dimension group setup is found under "Inventory Management > Setup > Dimensions > Dimension groups" and the dimension group is assigned to an item under "Item details > General tab > Dimension group field".

On the dimension group inventory dimensions can be marked as Active to become available for entry and selected for "Financial inventory" to be considered for costing purposes.

Imagine if you setup your inventory dimension group to have Size (inventsize), Color (inventcolor), Site (inventsiteid), and Warehouse (inventlocationid) to be active and financial inventory. This means that when inventory is issued (sold) the cost of the inventory is calculated based on all existing inventory that matches the combination of size, color, site, and warehouse. Another way of saying this is that the inventory is averaged by these dimensions.

Example

Inventory is purchase at a cost of $10 per unit for a specific item, size, color, site, and warehouse. Then the same quantity is also purchases for $20 per unit with the same combination of item, size, color, site, and warehouse. If the inventory is now sold, it will be taken out of inventory at a cost of $15 per unit. Any inventory receipts that match this specific combination of item and dimensions will therefor effect the issue cost.

Problem

One problem with this approach is that an item can only be assigned to one inventory dimension group. An example of when this can be an issue is when we want to cost items of one color one way and items of a different color another way. It would be possible to setup up additional items to accomplish this, but if this is a common practice you would not want to have to duplicate items to handle this.

Solution

One work around for this problem is to modify the code where the dimension group is found and used to use a different dimension group based on a dimension value. The way we handled this was to add a new field to the dimension group table (inventDimGroup) which references another dimGroupId on the same table. In this way we can assign one dimension group to an item, but then also assign special purpose dimension groups.

Once this is done the class InventOnHand::newFinancialUpdate() method should be updated to first inspect the inventDim passed in and then choose whether to initFinancialInvent with the passed in _movement.dimGroupId or with the new field we added to that table.

Example code

//Find the dimGroupId for RED items
redGroupId = inventDimGroup::find(_movement.dimGroupId()).dimGroupIdRed;

if(_inventDim.InventColorId == inventparameters.redColor && asnGroupId != "")
{
    inventDimParm.initFinancialInvent(redGroupId);
}
else
{
    inventDimParm.initFinancialInvent(_movement.dimGroupId());
}
//End

Adding fields to the Batch (InventBatchId) lookup

Background

By default in Dynamics AX the lookup control for the inventory dimension Batch uses your item dimensions for the breakdown of inventory when providing a list of On Hand lots to choose from. However, we've re-used the Serial Number dimension (InventSerialId) as a sub dimension to break inventory down by and set it as both a Primary stocking and a Physical inventory dimension. Because of this we want to select an inventory dimension combination when choosing a lot that matches the values for all primary stocking and physical inventory dimension.

Problem

When viewing the lookup control there is an option to "Range inventory dimensions". If this is selected then the InventSerialId field will show in the On Hand grid, but it will only show rows that match the dimension value for the selected line. If the "Range inventory dimension" option is not selected then the lookup does not display the dimension in the grid and furthermore it does not consider the field in the group by fields, thereby aggregating all values together. Since our goal is to return the selected value to the caller form this is problematic because not only can users not select based on this field, the InventDim record returned has the field as blank.

Solution

The solution is two-fold. First we must set the dimension field to display in the grid and second we must make it as part of the group by field so that the values are returned to the caller.

The Batch lookup form is InventBatchIdLookup. This form uses the InventDimCtrl_Frm_Lookup class to control it's appearance and behavior. Our changes can be made to this class.

InventDimCtrl_Frm_Lookup.findGroupByDimensions() is the method which sets the visibility of fields in the grid. For my purposes adding the following line of code as the last line in the method makes the field visible.

dimParmVisibleGrid.(InventDim::dim2dimParm(fieldNum(InventDim, InventSerialId))) = NoYes::Yes;

InventDimCtrl_Frm_Lookup.executeInventDimQueryDatasource() is the method which controls the shape of the query used to display and return data in the lookup (the group by fields). Adding the following line of code to make InventSerialId a sort field to this method also puts the field in the group by.

qbdsDim.addSortField(fieldNum(InventDim, InventSerialId));

Enabling a new inventory dimension and the AllBlank dimension Id

I recently explored the idea of enabling a new inventory dimension to track a new type of inventory in Dynamics AX. There were a few goals that I wanted to stick to.

1. Use one of the existing inventory dimensions rather than adding a new dimension. InventColor, InventSizeId, InventBatchId, and InventSerialId were all candidates.
2. While technically we would allow blank values, I wanted to have two explicit values to use rather than assuming blank was a meaningful value.
3. Due to #2, update all existing transactions in the system to be one of the explicit values.

The steps necessary to complete this are straight forward, but there are some words of caution I want to add along the way which I discovered in my investigation.