Retiring and Adding Cost Centers in a Live Four-Segment Chart of Accounts
Arboria Group has run Oracle Fusion General Ledger for 14 months on a four-segment chart of accounts: Company (balancing), Cost Center, Natural Account, and Product. The ledger allows dynamic insertion, and about 38,000 account combinations exist. Finance wants to add cost center 4500 (Robotics) under the existing Operations parent and retire cost center 3200 (Legacy Assembly), which carries three years of posted balances. A cross-validation rule created last year restricts natural accounts 6100-6199 to cost centers beginning with 4, and the first journal to 4500 was rejected with a combination error. Separately, the monthly Operations management report, which reads a published account hierarchy, still shows no activity for 4500 even though two journals have posted to it. The controller wants 3200 unusable by next month but insists that prior-year comparisons and drill-down remain intact. The shared-service team does not want manual workarounds or offline spreadsheets.
1. How should cost center 3200 be retired so that users cannot post to it next month while prior-year reports and drill-down still work? Address disabling, end-dating, deletion, and the effect on existing account combinations.
Read the worked answer
Do not delete the value. Deletion either fails once the value is referenced or destroys the ability to report history, so the safe route is to make the value unavailable for new activity while leaving posted balances untouched. End-date the segment value at the end of the current period, or disable it, then verify behavior on existing combinations: a value-level disable blocks new combinations and new journal entry, but an already-enabled combination containing that value can still be selectable in some setups. Close that gap by disabling the affected account combinations as well and, if the business keeps trying to use the value, by adding a cross-validation or segment-value security control. Confirm that reporting hierarchies still contain the value as a child of Operations so prior-year reports and drill-down resolve; hierarchy membership is independent of whether the value is enabled for entry. Test with a journal, a budget entry, and an allocation run, because each uses the value differently. Document the effective date so the change is auditable.
2. Why does the published hierarchy omit 4500, and what is the correct sequence to make it appear in the management report without breaking the prior published version?
Read the worked answer
Posting to a value does not automatically place it in a reporting hierarchy. The Operations report reads a specific published tree version, and 4500 was never added as a child of the Operations parent in that tree, or it was added to a draft version that was never published. Reporting and budgetary control consume the published version, not the draft. The sequence is: open Manage Account Hierarchies, create or edit a tree version for the chart-of-accounts hierarchy, add 4500 under the Operations parent, validate the tree for overlaps and missing parents, then publish the new version with an effective date. Publishing a new version preserves the older version for historical reporting and audit, so prior-period reports continue to resolve against the version that was effective then. After publishing, rerun the management report and confirm the two existing journals roll into the Operations total. If the report also depends on a segment-value set or an account group, check that 4500 is included there too, since hierarchy publishing alone does not update those objects.
3. How do you resolve the cross-validation error for 4500, and what should happen to combinations that already exist but would now violate the rule?
Read the worked answer
First read the rule precisely. In this case the rule allows natural accounts 6100-6199 only when the cost center starts with 4, and 4500 does start with 4, so the rejection is probably caused by a different segment in the entered combination, by a rule condition using a range or parent value that does not include 4500, or by the rule being evaluated against a value set that 4500 was not yet in when the journal was attempted. Test the combination through the validation or combination-inquiry function to see which segment fails. Fix the configuration rather than disabling the rule: extend the condition to the correct cost-center range or parent, or correct the journal. For existing combinations, enabling or changing a cross-validation rule does not rewrite history, but the combinations may fail validation the next time they are used. Identify violators with a combination extract, decide whether to remediate them by changing the cost center or natural account, or to exempt them explicitly, and only then enforce the rule. Log the decision because auditors will ask why some combinations remain non-compliant.