Release 12 is in your future whether you are drawn by the new functionality or pushed by the coming “retirement” of release 11. To make that move, there are two ways of proceeding – the Oracle provided upgrade or a reimplementation. Regardless of your reason or the method you plan to use, your results will be better and the process will go more smoothly if you change your chart of accounts to be exactly what you want beforehand.

The CHANGE – TEST – UPGRADE advantage begins by getting the results you want in Release 11.

The ideal way to obtain the chart of accounts that best fits your business is to be able to see exactly what your business looks like using the new chart of accounts. A properly ranged chart of accounts reduces the number of cross validation and new sub-ledger rules that your staff needs to write. A changed chart of accounts can save resources by eliminating unused segments or code combinations.

The available software for changing charts of accounts begins by operating in a test environment where you can go from mappings to a fully testable result in hours. Besides ensuring that there are no errors, testing permits you to see the results and change the mappings if the result was not as desired. It is a modeling process that allows you to see “what if” these segments were mapped together, or what if I added another segment to track a new area of the company. The upgrade then becomes as straightforward as possible – no changes to the accounting structure are being made as part of the upgrade.

If you have decided to reimplement, you have probably made the decision to bring over only a small amount of history into Release 12. You’ve made the decision to reimplement because you want to take advantage of the features of 12, and also because your e-Business Suite has not changed to meet your current business. The typical way to load the history into a new implementation is to load the transactions using a loading tool. However, if you are loading from one chart of accounts to another, that load script needs to include the conversion of the first chart of accounts to the second. If you are changing charts of accounts, you are creating a very complex scenario for your developers. They will have to map and translate the accounting for every transaction to the new chart. The testing becomes even more difficult because you must test to see that the data loaded correctly, you must reconcile your new chart of accounts with the old one, and you must test the new chart of accounts in every module. By changing the chart of accounts first, the load becomes a “clean load” with no mapping and translation effort for the migration.

The CHANGE – TEST – UPGRADE method creates a clean audit trail and creates the SOX compliant reports that show the history of the changes for every transaction. You have a baseline of reports that you generate before changing the chart of accounts, you have a listing of everything that has been changed, and you have the same reports that are generated after the chart of accounts change. If the change is done as part of the load process, you lose the audit trail. The changes are effected in Release 11, which is what your staff has worked with before, and allows them to test and reconcile the data to provide a baseline for comparison before the move to Release 12. The upgrade that is required is as “vanilla” as possible – apart from moving the data from 11 to 12, no other changes are being made. The more complicated upgrade functionality that permits changes at the sub-ledger level is not employed, nor will that part of the Release 12 functionality be needed. The complexity of Release 12 makes staying as close to its mainstream as possible a prudent strategy.

The benefits of the CHANGE – TEST – UPGRADE method are many, varied, and substantial. Those benefits can only be obtained by changing your chart of accounts in Release 11, before the upgrade to Release 12.