We are pleased to announce the availability of KB 3030212 “Duplicate InventDim records are created which causes errors in the WHS if license plate IDs include trailing blanks”. The KB introduces the capability of resolving duplicate InventDim records.
This blog post contains information about what can cause the inconsistent inventory dimensions to be created and how to correct these.
How to prevent the issue from occurring: Go to CU8 or implement small code change
Microsoft Dynamics AX 2012 R3 RTM Warehouse Management: How to prevent the creation of two inventDim records considered identical in Dynamics AX 2012 R3 RTM
After installing KB 3030212, multiple steps must be carried out in order to fully correct the inconsistent data. It is a prerequisite that Ax2012R3 CU8 is applied or the small code change referenced above have been implemented.
Overview of the problem
The inventory dimensions that we will consider as part of the consistency check fall into the following categories:
Inventory dimensions that are incorrectly hashed and have a duplicate which is correctly hashed
Inventory dimensions that are incorrectly hashed and do not have a duplicate
The dimensions from category A will be considered identical from an AX point of view since that dimension values are the same but only the hash value differs. This can lead to erroneous situations in downstream transaction processing. The ones from category B do not lead to erroneous situations in downstream transaction processing. However as they have the potential to move to category A, and cause future downstream processing issues, they are also addressed in this blog post.
Step 1 – Run new consistency check
Go to System administration>Periodic>Database>Consistency Check. The new consistency check for Inventory dimensions is available under Inventory management Check and is labelled “Inventory dimensions”.
![]()
The new consistency check will only deal with inventory dimensions that are incorrectly hashed and have a duplicate which is correctly hashed (category A).
It will detect these and attempt to update all references to use the correctly hashed inventDim record.
Some tables such as InventSum and WHSInventReserve have inventDimId as part of a unique index. As such it might not be possible to update the inventDimId, since such an update could cause index violations. The consistency check deals with these two tables by merging the records.
The consistency check will output information about which inventory dimensions are incorrectly hashed and which records have been updated.
Step 2 – Clean up inventory dimensions
Once the consistency check has been run, the incorrectly hashed inventory dimensions having duplicates should not be referenced any more.
Next step is to run the Inventory dimensions cleanup job, as this job will remove the incorrectly hashed inventDim records. This can be done from the Inventory Management>Periodic>Clean up>Inventory dimensions clean up.
![]()
Step 3 – Re-hash inventory dimensions
Once the first two steps have been run, you have resolved the issues related to category A issues. However category B issues may still exist: InventDim records incorrectly hashed and referenced. This final 3rd step will update the hashValues of these records.
This is achieved by running the InventDimUniquenessEnabling class which has to be done by opening the class directly from the AOT.
![]()
Time required for consistency check, Clean up inventory dimensions, and re-hash
The time required for the 3 steps above depends on the number of records in inventDim, the number of incorrectly hashed inventDim records, and the number of records that are referencing the incorrectly hashed inventory dimensions.
When writing this blog post, internal tests have been carried out on a dataset containing 1341990 records in InventDim. The hardware was a single core virtual machine with 16 GB ram. The overall time spent executing the three steps above were similar to the below:
Step | Approximate duration in minutes |
1 | 2 |
2 | 15 |
3 | 7 |
Please be aware that approximate duration in minutes will depend upon HW setup, data composition, load, and concurrency. Your actual performance when running the three steps above will deviate from the above table and be specific to your implementation. The numbers are merely provided to give an idea of the possible duration.
This KB is available for Microsoft Dynamics Ax2012R3.
![]()
![]()
