Recently I taught an introductory class on Oracle’s JD Edwards EnterpriseOne General Ledger module. I posed this quiz question to the class to bring out how the soft coding attributes around a chart of accounts can prevent the “hard coding” of organizational structure or other logic into the account — which are always very difficult to change later after an implementation has gone live. Here’s the quiz question:
The Object account represents the “what” of a journal entry, such as cash, sales revenue, cost of goods, travel expense, etc. The next field, the subsidiary or sub-account, when used as intended by JD Edwards in best practice, represents:
A. A more detailed slice of the object account, such as air travel expense
B. A departmental characterization, such as sales department travel
C. An individual entity, such as sales to Customer ABC.
D. All of the above are best practices
The right answer is “A” because if the object account represents travel expense, then a good or “best practice” use of the subsidiary or sub-account is to break this down further, such as air travel expense, lodging travel expense, etc.
Answer “B” is not a best practice because in JD Edwards, the object/subsidiary part of the account entry is always prefixed with the business unit (aka cost center or department). And the business unit itself has 50 user defined ‘category codes’ to soft code it’s meaning, such as “Sales Department” and “Northeast” — using two of those codes. So if the region is redefined as “MidAtlantic”, then you simply change the value of the code, with no impact on the design of the chart of accounts.
Answer “C” is wrong is a similar manner because of the ability to ad-hoc append a very granular “sub-ledger” value — such as the address number of a customer or supplier or employee, or a work order number, or a machine asset ID — to the transaction. Again, there is no reason to ‘hard code’ this type of meaning into the chart of accounts.
Yet, I saw a presentation from a webinar recently in which the object account was being hard coded to have specific meaning. The 1st 2 digits of the object account were being used to identify a department/division and the next 2 digits (positions 3&4) were representing the type of amount (i.e. asset such as cash, liability such as AP, revenue such as parts sales, expense such as labor). This is a hard coded approach that can only lead to lead to trouble later on if and when “things” change.
A better approach would be to let the department designation reside with the business unit. And to have the more detailed information in positions 3 and 4 either be an object account, or a subdivision of the object account using the subsidiary account.
In any event, sticking to the proscribed soft coding capabilities of your system will increase your chances of having “Your System: Not Guilty as Charged.”
Your System - Not Guilty As Charged 