Using Record Info and the importance of field groups on a form

I've often wondered about the Best Practice check in AX that requires all fields to be in a field group and why that is there. I assumed it was some sort of encouragement to use field groups on forms and reports, but today it occurred to me that there is another very valuable tool that uses this information (there are probably many others as well).

If you have the appropriate permissions in Dynamics AX you can right click on any field on a form, select record info, and then select "Show all fields" to open a new form which displays all of the fields in the table and their values regardless of if the field is on the form or not. This is useful for some power users if they are interested in knowing when a record was created or when it was last modified for instance.



Show all Fields

 

I shared this functionality with a user this week, but it wasn't until today that I realized how this form organizes fields into groups based on field groups to help the user find them. So in the future take some time and consideration when creating field groups or adding fields to groups so that users can find these more easily on the Record info screen.

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

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.

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.