Friday, December 28, 2012

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

Friday, July 27, 2012

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));

Monday, May 28, 2012

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.

Tuesday, April 3, 2012

Aggregate, Group by, and Having functions in SysQueryForm

Have you ever wanted to use the SysQueryForm in Microsoft Dynamics AX to define a query that had an aggregate (sum, min, max, etc.) and a group by clause? In Microsoft Dynamics AX 2012 this is now possible. Read on to learn more about this little known feature.


Saturday, March 17, 2012

ParseXPOs

Many people may be familiar with the CombineXPOs.exe utility for Dynamics AX that mfp has shared on his blog. This utility is useful to take many individual xpo files and create a single large xpo file that can be imported into Microsoft Dynamics AX either from the command line or manually in the client. I recently had a scenario where I wanted to do the opposite, export a large project from Dynamics AX and then parse the project into individual XPO's. This was useful to compare all of the objects installed in a layer in multiple enviroments. Hit the jump for the source code and binaries.

Friday, March 16, 2012

Migrating from MorphX version control to TFS version control - Part 2

In Part 1 of this article I described a method to migrate MorphX version control data into TFS version control using the TF.exe command line utility and an x++ job. In Part 2 I will touch on some of the difficulties I faced and give a little more detail on how I overcame them.

Saturday, February 25, 2012

Migrating from MorphX version control to TFS version control - Part 1

There are quite a few good topics on the web about how to use TFS for source control in Dynamics AX but one thing I couldn't find was anyone with a way to migrate from MorphX version control to TFS version control.

Wednesday, February 22, 2012

Welcome

Welcome to my new blog about Dynamics AX.

I've spent the last 5 years working for a vendor for Microsoft helping build the public sector solution for Dynamics AX. I worked on versions of AX before 2009, on the entire release for 2012, and also on the start of the next yet to be released version of AX.

Recently I started working as the Sr. Dynamics AX developer for a private company that uses Dynamics AX internally.

Most of my prior experience working on AX was admittedly in the financials module but in my new job I will be getting very familiar with the inventory module. I'm also very interested in architecture and the build environment so some of my initial posts will be in the area of setting up a development environment for a private company.

I hope you enjoy my posts and that I'm able to offer some of my unique insights to the online discussion of Dynamics AX.