Orphan Transactions - Changing the Dimension group of a Standard Cost Item

Update conflict. The standard cost does not match with the financial inventory value after the update. Value = ###.##, Qty = ###.##, Standard cost = #.##

This is an error we come across quite many times in AX 2009, while trying to post transactions against an item. Most often, it is during Purchase Order posting. While the cause is clear, it is still a dilemma as to how the system runs into this situation.

The Cause:

In AX, users can set Inventory Dimensions for an Item. These dimensions, once set, and once there are transactions created with them, are not changeable. In most cases, the system throws an error while trying to change the Dimensions on the Item where transactions exist for the item.

Note: There need not necessarily be 'open' transactions against the item. The default behavior is that that as long as the item is 'used' in any transaction, irrespective of whether it is open or not, the system will not allow the update.

In rare cases, and absolutely at random, the system allows the change in Dimension even when transactions exist for the item.
There is no definite reason as to why this happens. But nonetheless, it happens. When there is a Batch dimension attached to the item, it becomes a greater concern.

The Issue:

The Items for which this error occurs had the Inventory dimensions changed from one that had a Batch dimension to one that did not. These transactions then become "bad" transactions in the system and cause this error.

Depending on the item, there will either be a negative inventory (physical negative inventory enabled on the Item model Group) or there was a Positive inventory in the system, for the quantity available.
Ideally the inventory must be zeroed out before any such update is done. When trying to update the Inventory for these items, the system creates an issue. Since the Batch Dimension is no longer an active Dimension for the Item, transactions cannot be posted with a Batch number. The transactions that were already existing in the system are now "orphaned" by this update. The transactions with the batch were duplicated in the system at the same location, but without the batch dimension.

To add to the confusion, the Standard Cost does not update properly, for all the lines of a particular item in the InventSum. This is again because there are some transactions with Batch Dimension active and some without. The Standard Cost does not understand how to handle these "Orphaned" transactions and the issue compounds.

The biggest issue in this case is that the Dimensions can be changed a long while back or more recently, and the Standard Cost update will sometimes not throw any error (again, there is no logical explanation to this scenario). The point is, the updated could have happened long before the error throws up (In my most recent case, the update was done 3 years ago.!!)

How the system Works:

While looking up the totals for an Item, AX queries the InventSum table or the InventTrans table using some predefined macros. The #InventDimJoin macro queries the InventDim table and the InventDimParm table to fetch the total quantity for the Item based on the Inventory Dimensions that are Active for the item.
Here, the "orphaned"/ "bad" transactions get added into the non-batch transactions, with the same active transactions (but without batch dimension). Since Batch number is not an active dimension anymore, it gets ignored.

When the totals are calculated, some of the transactions match the Standard Cost for the Item, while some don't. If the Site-Warehouse where the transaction is being updated matches with the Standard Cost, the system allows the transaction. In case there is a mis-match, the error occurs.

The Solution:

The issue occurs at random and there is no exact reason for the system to be in this situation. There is, however, a solution to the above issue.
Do note that the solution may not always fit the problem. It is one of the possible ways to fix the issue at hand. (The Debugger is a handy tool in most situations).

 - First, evaluate the existing transactions in the system and determine the cost for each of the transactions.
- Use the fill utility to change the item's dimension group back to one that uses the Batch dimension.
Here, we are updating the dimensions for the transactions in the InventSum table for the particular Item. By using the fill utility, we ensure that the check for the Active dimension is ignored..
- Once this is done, the transactions can be updated in the system. Do ensure that the Standard Cost for the Item matches with that on the "orphaned" transactions. (The Standard Cost may have to be updated in this case)
- Use the Item Journals to add/remove the Inventory of the affected items as required.
- Use the fill utility to update the dimension group.
- Move this "updated" inventory back with appropriate costs, and without batch numbers this time

Note: The system considers both the Quantity and the Cost while building up the On-Hand for the Item. If the totals for both are not absolutely zero, the transactions will still exist in the system and there will be a record for it. This will lead to the same error in the future.

Workaround:

There are some cases where only one transaction is affected for an item. In such a case, first, determine exactly which transaction is affected for the item.

Then, go to the InventSum table and narrow down to the transaction. Here, in the PostedValue field, update the cost to match the Standard Cost of the Item. Ensure to take into consideration the Quantity posted against this particular transaction and make the update accordingly.
Be extremely careful while making the update. The InventSum is a core table for all item transactions and any error will have huge impacts in the system.

Caution: Do not directly update the Costs and Dimensions in the Live/ Production system. Try the update in the test/ development system first to check if all the transactions are being updated correctly. Then, take a DB backup of the Live system and then update the costs in the Live system.
Also ensure to totally nullify the "orphan" transactions. Otherwise the error will crop up again.

Again, this is just a suggestion as to what needs to be done. Consultant discretion is advised.

P.S. Please leave comments below in case there is any other way to fix the issue.