Lessons Learned: Unit of Measure Conversions in Microsoft Dynamics AX 2012

Microsoft Dynamics AX 2012 offers clients versatility and advanced capabilities to utilize various units of measure (UOM) for different business areas and functions. This is vital, because AX 2012 users often wish to inventory material in one UOM, while at the same time, purchasing or selling the same material under a different UOM.

However, AX 2012 users beware—there are some dangerous gaffes you may encounter with UOM conversions.

PROBLEM # 1 – Configuring Unit Conversions in Both Directions

When setting up unit conversions, users may be inclined to setup the conversion so that both directions are identified in the conversion table.

An example of this might be that the user desires to store product number 8002 with an inventory UOM of "SqFt," while also using a sell UOM of "ea." In order to support this practice, the user must define the conversion between SqFt and ea for the item.

AX only requires that a conversion exist in one direction. In other words, the user can define the conversion from SqFt to ea OR ea to SqFt.

Acceptable configuration of this conversion assuming 160 SqFt per 1 ea:

AX is capable of converting from SqFt to ea, as well as from ea to SqFt, based on only having the conversion configured in a single direction (as previously noted). However, the system will not prevent the user from defining the conversion in both directions.

The problem with setting up the conversion in both directions is more than just the redundancy of the input—the user opens up the risk that the conversions won't be consistent. If the conversions are inconsistent, it will affect that way AX rounds in that AX will first look for the directly applicable conversion, before then going to the inverse conversion.

An example of the problem, using similar data from above, would be the following:

This example shows that the conversion has been defined as 162 SqFt = 1 ea in the first record, but 1 SqFt = 0.00625 ea in the second record. A closer look reveals that the second record actually correlates to 160 SqFt = 1 ea. Because various transactions in the system may convert from one direction or the other, having this inconsistency will inevitably lead to transactional integrity and rounding issues.

SOLUTION #1: Establish a business practice to configure and maintain unit conversions in a single direction, and run some basic reporting analysis to verify the conversions are setup accordingly. This will avoid the problem of mismatched conversions and the downstream ramification of transactional errors associated with such problems.

PROBLEM # 2 – Changing Unit Conversions After Transactions Exist

Another problem is the need to adjust or modify unit conversions after the original configuration is in place. There are various impetuses for such changes: conversion factor changes based on chemistry or lab results; a business process change to extend decimal precision; or even the revelation that the initial conversion was established incorrectly.

Nonetheless, changes to unit conversions after transactions exist in AX are extremely dangerous and should be managed with caution and due diligence.

The following is an illustration of how a unit conversion change can impact your ability to successfully execute transactions in AX.

Scenario:

• Sell UOM: Lb
• Inventory UOM: Ft

Sequence of events:

1. Original conversion: 1.00 Lb = 80.6106 Ft
2. Sales line created for 100.00 Lb
   1. Back-end inventory on-order transaction (inventtrans) created for 100.00 Lb x 80.6106 Lb/Ft = 8,061.06 Ft
3. Production order created and processed to report as finished 10,000.00 Ft into inventory
4. Sales order picking list created to pick 8,061.06 Ft
5. Conversion change: 1.00 Lb = 80.6506 Ft
6. Sales order picking list registration process
   1. Picking clerk registers the 8,061.06 Ft to fulfill the order.
   2. System then converts the 8,061.06 Ft back to Lb to net the delivered quantity against the ordered quantity of 100.00 Lb. The result is 8,061.06 · 80.6506 = 99.95 Lb. As such, shipping documentation will show a shipped quantity of 99.95 and a backordered quantity of 0.05 Lb. Likewise the deliver remainder on the sales line will be 0.05 Lb.

The problem above is exacerbated as the quantity or conversion scale increase, but this is just a representative example. Many other scenarios will produce similar results, and in some cases, users may actually be unable to process the transaction due to rounding errors and discrepancies between the old and new conversion results.

SOLUTION #2: The only way to properly protect against the pitfalls of unit conversion changes is to close all open transactions for an item (or items) involved in the conversion prior to making the conversion change. In many cases this may mean deleting or canceling open order lines, adjusting the conversion, and then recreating the deleted/cancelled order lines.