The Pro 5.0 version of Design Manager was created for computer systems of the late eighties and early nineties that did not have near the processing power or data storage capabilities of computers today. For this reason the 5.0 software required certain storage techniques to run efficiently on those older systems. In many areas of the accounting system, detailed entries needed to be combined into summarized entries to save storage space and speed look up. When these summarized entries were created, details about the entries and how the individual accounts were affected were lost. For example, in 5.0 when an A/P vendor invoice is posted to Cost of Goods sold an account is entered on each component of the PO. When this information is posted, the transaction is summarized by account, this does not make possible to know exactly which number in which account belongs to which component. In other words, you can say that a certain list of components on a PO produces certain accounting activity but you cannot from the accounting activity reproduce the list of components.
In newer versions of Design Manager, storage and fast lookup of these references have become possible. Therefore, when the data is transferred from the 5.0 system to a newer system such as 6.0 or 7.0, the computer must extrapolate the summary information recorded in Pro 5.0 into the details needed by the newer version of DM to satisfy the reporting requirements of the newer system. This extrapolation is an inexact science and is done my taking account balances and distributing them to line items and PO component items. This, in many cases, causes accounts to be classified incorrectly and for details that are simply missing in 5.0 to be reconstructed entirely. Since 5.0 does maintain a list of balances in each account (trial balance information), the system takes the difference in each account for each month after the data is converted and creates an entry with the journal entry number of DCADJ to make the new system’s account balances match the 5.0 system.
For example, in 5.0 when a credit invoice is created, the details that constitute the credit and its original invoice are combined into one transaction. This presents a problem for the data conversion especial if the original invoice and its credit are in two different months. For this reason, the conversion does not converted these credits at all, instead it relies on the DCADJ journal entries to make up for the differences between the account balance in the old 5.0 and new DM in order to record the credit correctly. Another example is that if a certain COGS or expense account is used on an operating or PO related expense in 5.0 the system. The system will take all components that post to the same account number and add the net effect to the account together and record only the total in the General Ledger. When the conversion programs converts this from 5.0 the new DM, it will use a generic account number and thus relies on the DCADJ entries to reclassify the amount to the correct accounts.
The long and the short of all this is that the DCADJ journal entries make the conversion from 5.0 to a new DM possible and although you will see them in month of and in months prior to the data conversion in your new DM, they can be completely ignored as they are there only to make the accounting history in the new system exactly match what was in the old 5.0.