Last week we had our webcast: “Convert Data to R12 On-time and On-budget”, which invited everyone to rethink data conversion. Today we bring you the transcript of the Q&A session. Remember you can always review the presentation here in case you missed it.
In a typical Oracle EBS implementation schedule, how many iterations of conversions are needed? Is it dependent on volume?
The number is majorly dependent of the number of test cycles you are willing to do for the implementation. In CRP 1 there will not be any conversions because that is where data mapping and conversion strategy is happening. So the number will be CRP 2, CRP 3, UAT and production. So if there are 5 total iterations, it will be 4 major rounds of conversions for all master and transactional data.
What is the sequence of data to be converted in terms of modules? Is this based on dependencies?
The first and foremost thing that should go into the system is the master data. Validated, and make sure that each master data element is broadly available, because when we load transactions there’s a chance that many records will fail – and 90% of the time it’s because the master data has not been properly loaded. After all the master data, the transaction data can follow. In a typical Oracle Financials and SCM re-implementation / implementation, GL Code combinations should get loaded and validated first, as for many other master data conversions, account code combination is a pre-requisite. In AR/OM perspective, Customer Master Data should be loaded first as all AR and OM transactions are fully dependent on customer master data and so on.
What should be the approach to handle error records / fall out records?
In all Master data loads, error records can be left during initial runs, fixed at source level or Interface level and loaded again. This is because each individual record is independent of another. In case of transactions, it is business’s decision whether to reject entire batch if there are some error / fall out records or load partially. However, it is always advised to error out header records if any one of the details / distribution records fail.
Also, business leads should be made responsible to take a call on data cleansing and deciding on fall out records, case by case.
Historical data conversion, what are the requirements across the clients?
Historical data conversion, for past few /several years is mostly requested by clients in General Ledger. Helps them in maintaining all JEs and balances in the re-implemented instance readily available. This is also dependent on local statutory requirements. Sub ledgers data, if there is a need to bring historical data too, increases the complexity of data conversions, however some clients prefer to maintain them in legacy / archived instances and some clients prefer to bring them over to new instances.