This blog post is part of a series with special considerations for high-level data migrations to Oracle Cloud ERP. Previously, we shared a blog post Oracle Cloud ERP Data Migration Recommendations and Best Practices focusing on the data migration across Oracle Cloud ERP. The blog post provides guidance on the approach to convert master and transactional data for business objects in Oracle Cloud Applications, including Financials, Procurement, Project Management and Related HCM business objects (Employees, Locations).

In this post, we discuss additional considerations for high volume General Ledger (GL) data migrations. The considerations are intended to be generic and do not relate to a specific organization or industry.

We typically recommend you convert two years of GL balances and one year of journals into Fusion General Ledger. Despite managing the conversion scope, you may find that you still have to convert millions of journals. If that is applicable to you, consider the following:

  • Configure the required GL settings before running the Import Journals process.
  • Create the account combinations in advance of your data conversion. Use the Import Account Combinations FBDI solution to create the combinations. 
  • Disable any Cross-Validation Rules before starting the migration import process.
  • Disable sequencing for GL conversion data as it impacts the Posting runtime
  • Disable Budgetary Control for GL conversion data if no control budgets are defined
  • Define your import process parameters and schedule to use automatic processing. 
  • Enable AutoPost for your sources and ledgers.
  • Set the period status to either Future-Enterable or Open. Journals can be created by the journal import process in a future enterable period, but not posted. Posting requires an open period. 
  • Open one GL period at a time. Import, post and reconcile the journals before closing the current period and opening the next one. The period you are converting should be the latest open period.
  • Run the Optimize Journal Import Performance process before running the journal import. The job is available under the Granted Role: General Ledger Technical Administration privilege. See the MOS Doc ID 2559114.1 for more details.

Data Preparation

Create separate data files for each source, ledger, and accounting period. 

  • Create CSV files instead of using the available FBDI Excel templates. The CSV files do not have a row limit as Excel does.
  • The number of transactions in the CSV file should be limited to 1 million records. Each file should have a unique Interface Group Identifier (Group ID).
  • For any associated reporting currency (ledger) or secondary ledger, import the balances directly instead of replicating them through posting journals in the primary ledger.

Journal Import

Pre-validate the data before uploading the files to the GL interface table. Make sure the source data is mapped to the correct Fusion General Ledger attributes like ledger names, journal sources, journal categories, period names, or Chart of Accounts (COA) values.

Export data from your legacy systems: extract the data from the legacy system, generate the CSV data files, upload the files to the GL interface table.

Run the Import Journal process. 

  • Submit up to 20 Import Journal jobs in parallel for a combination of Ledger, Source, and Group Id. The limit depends on the ESS thread capacity in your environment.
  • If the import process completes successfully, journal entries are created. If the process fails, the error lines are loaded into the Correct Import Errors Spreadsheet. See the MOS Doc ID 2442750.1 for instructions. After correcting the errors, run the Import Journals process again.
  • Never submit multiple Import Journals jobs for the same ledger and source with “All Group Id” option as this would create contention in the system. 

Post Journals

After the journal entries are created in Fusion General Ledger from the imported data, post the journals. 

  • The posting process validates the data and records it in both the General Ledger tables and the balances cube. You can review posting errors in the Posting Execution report, the Journals Dashboard and in the Manage Journals page. You can correct the errors and run the posting process again.
  • Post the batches using AutoPost. Make sure each ledger has a separate Posting Priority or separate AutoPost Criteria Set, so that all batches for a ledger are posted by a single posting process.
  • Once all batches are posted, reconcile the data and balances with the source. Start with the totals by source, batch, period, or journal, etc. If there are discrepancies, drill down to compare the source journal lines and account combinations.
  • Run the Purge Interface Tables process to improve performance of the import jobs.

Conclusion 

Carefully plan and test your data migrations. If you are converting high data volumes, we recommend that you review and follow our recommendations above.