First, what is a GL class code? This code is 4 characters in length, is assigned by item, and is located in several places across many modules in JD Edwards EnterpriseOne. It is assigned when a new item is created as part of the item master set up, and then gets propagated down to item branch, location, sales order, and purchase order records. It is also an integral part of the distribution/manufacturing automatic accounting instruction (DMAAI) configuration. So, what is the issue we speak of? An issue may occur when one of these codes needs to be changed. JDE E1 allows changes to each of the individual fields without checking if there is any quantity on hand. This, in my opinion, is a mistake. GL Class codes should only be changed when the quantity on hand for the item is zero! Not following this rule can and will cause reconciling items at period end.
How is that possible? Consider the scenarios below. In scenario 1, the item was misclassified as a finished good and needed to be changed, but a receipt for $100 has already occurred. The GL class code was changed between the OV and the subsequent IM transaction while there was a quantity on hand. The IM then credited the raw material account because of the code change. Finished goods were never relieved, causing an account discrepancy!
The lesson learned here is there should be a process when changing a GL class code on an item or it will cause a JDE inventory reconciliation issue. Make sure the quantity on hand is at 0 before making the change. It may be a little more complicated but, in the end, can save you reconciliation headaches! With scenario 2, the quantity on hand was adjusted out BEFORE the gl class code was changed. The first IA transaction zeroed out the finished goods account properly. Once the code was changed, the second IA debited the raw material account in preparation for the relief with the IM transaction. All is as it should be!
Until next time when we'll cover JD Edwards inventory reconciliation issues (part 3) … happy reconciling!