OracleScene

D I G I T A L

WINTER 14
E-Business Suite

Don’t Look
The challenges
of historic data
migration in
E-Business Suite

Back in Anger
The saying goes ‘be careful what you wish for, you may get it’ and this is very relevant
to data migration, especially migrating historic data. There are some large technical
challenges to overcome when migrating history and once these have been overcome
and E-Business Suite is full to bursting with data, there are some large business
challenges reconciling it all. This article aims to explore some of those challenges and
how you might get around them.

Michael Lane, Managing Technical Consultant, Claremont

If you have been involved in (or are about to become involved in) To be clear: we’re talking about transactional data here (invoices,
an ERP implementation you can imagine the initial meeting to orders, payments etc) rather than reference data (customers,
discuss the scope of the migration: inventory items, suppliers), although they both need each other
to exist in E-Business Suite.
• Your IT team or systems integrator wants a simple migration,
so their opening position is open or active data only should be From a business perspective it is very difficult to carry out some
part of the migration i.e. leave the historic stuff where it is. functions without the data actually being present in E-Business
• Your users usually want most of what they have now, i.e. the Suite. Advanced Collections is a great example of this. It’s
transactional, financial and accounting history relating to difficult to apply collection strategies without having a view on
all activities surrounding their customers/suppliers/factory/ the invoice vs. payment performance of the customers. CRM
warehouse/engineers. is another good example, where your relationship with your
customer is framed around the business you have done together
and therefore the transactional data.
Both perspectives are equally valid. From the So how to reconcile these positions? What are the challenges?
IT perspective, E-Business Suite does not make What are the alternatives? I’ll use some examples from recent
Claremont migration projects:
it easy to migrate historic transactional data
and there is a simple explanation as to why. Historic GL Journals or Balances: Technically one of the easiest
migrations to build (slightly more complex if you use multiple
currencies but not massively so), but watch out for a few
The mechanisms used for data migration, i.e. the open hazards with this one. Firstly you need your historic period(s)
interface (table/concurrent program - batch) and the API (PL/SQL open, the various segment value sets need to have all your
– row by row), are designed to apply the same validation as you historic values (don’t forget to take them away afterwards),
would get entering the data via the E-Business Suite screens. cross-validation rules may need to be disabled during the load.
And the E-Business Suite screens assume that once you have The challenges are obviously greater if you already have Oracle
spent time entering the data you might like to do some sort of GL up and running as the period, value set, cross validation rule
processing with it, e.g. record some payments if you have just changes are trickier to make in an already live system.
entered a new invoice into AR. E-Business Suite does not
expect you to enter transactional data just so you can report Closed AR Invoices: Always a popular request with the clients (my
on it and refer to it. last two projects both asked for it and got it) and can be tricky. As

30 www.ukoug.org
 E-Business Suite: Michael Lane

previously mentioned, Oracle does not allow closed transactions meaningless. Consider the following example:
to be directly entered into E-Business Suite so in this case you • Invoices 100, 101 & 102 all occurred in the last FY and are
must first load an open invoice and then close it either by therefore in scope for migration, these are imported via
applying a receipt against it or crediting the balance with a credit AR Autoinvoice as open items.
note. Last year we worked on a R12 European roll-out to nine • Receipt A200 was received in payment for invoices 100 &
countries and this was a central migration requirement. 101 in full, but only part of the balance for invoice 102.
• The remainder of invoice 102 was paid for by receipt A201,
If you follow the applying the receipt method then you must however A201 also paid invoices 99,98,97 & 96 which
also migrate the receipt. There are two common methods occurred in the FY 2 years ago – you’ve just had scope-
for doing this as I’ll describe below. The first is technically creep because you want an accurate reflection of what
straightforward and a nightmare for the business, the second is the customer paid you so you need both receipts and all
the reverse case. invoices related to them.

• Create individual receipts which match the open invoice

amounts and close the invoices in 1:1 fashion. This is the
easiest approach for IT to take, but gives you a reconciliation
By the way, I’m not making this up. We
headache as you have just made up a bunch of receipts solely faced exactly this situation last year. The law
for the purposes of closing some invoices. Those receipts were
never paid to you in the way you now see them in E-Business
of diminishing returns applies here so we
Suite. Our nine country rollout client had used this method chopped the process off before it went too far.
when migrating to R11i some years previously and all the
European units swore blind they would never use the same
method again, as they appeared to have spent the time since The farther back you go, the less valuable the data becomes.
going live on R11i sorting out the mess in AR.
• Re-create the receipts as they were paid to you. In reality One last point on historic AR; watch out for tax codes. Legacy tax
medium and large sized enterprises get paid for more than codes may not exist in E-Business Suite and may even use rates
one outstanding invoice on one receipt (certainly the case in which are no longer available, but were when the invoice was
the European rollout). The challenge with this is that, where raised. These will need to be configured in the E-Business Suite
you may have set a time limit on your historic migration e.g. tax modules for the duration of the migration.
we’ll go back to the start of the previous financial year, trying
to replicate AR invoices and receipts can soon make this The key message is, if your migration is going to deliver
>>

www.ukoug.org 31
 E-Business Suite: Michael Lane

something of value to the business then it is going to have to go In terms of effort from the project team, there is one very simple
down the more difficult path. rule: the more data you migrate the longer someone has to spend
reconciling it with the source system (hence the quote in the
You also have to take into account the GL transactions that all opening sentence of this piece) and there is never enough time in
this new sub-ledger data is going to generate. The approach the plan to carry this out. Some pointers from recent projects:
we took was to allow AR, GL, FA and the rest to push their
accounting entries into the GL, post the journals and reverse • Get the business (not IT) to identify the reconciliation reports
them, so you end up with zero GL movement from your historic in the legacy system at the design stage (when you’re writing
transactions. One of our current clients uses Oracle GL as the your CV.010 conversion scope document) and make sure they
ledger for a range of non-Oracle applications (these applications have the right level of detail.
being the ones we are now extracting data from to import into • Don’t use the standard E-Business Suite report for
Oracle), so we have to be careful not to double count revenue for reconciliation, at least not in their current form. It’s much
example when pulling the history into E-Business Suite, as it had easier to borrow the SQL from these reports and get the
already been accounted for in a prior period. data into Excel (you can still easily compare the report totals
with the E-Business Suite output) which is wonderful for
Some related challenges: reconciliation. The standard reports don’t lend themselves
• An historic AR data migration means you must load the well to Excel.
(possibly) now historic customers into E-Business Suite before
the transactions can load. The customer migration can be
tricky as it has a lot of separate parts which clients tend The Alternatives?
to consider part of their customer record, but are in reality The most obvious: don’t migrate the data unless is actually
separate migrations in their own right, e.g. bank accounts forms part of a business process you want to implement in
(don’t forget to load the banks and branches first though), E-Business Suite, e.g. Advanced Collections. Organisations
notes, contact points etc. rarely throw the old system away (bear in mind there is a legal
requirement to retain certain types of data) so you may still have
AP Invoices. To migrate a closed AP invoice it needs to get read access to it. And in a lot of cases that’s enough.
paid in E-Business Suite and the payment has already gone to
the supplier from a separate system. Again, you’d be double
counting if you pay it again and because of Oracle Payments
configuration surrounding payment documents E-Business Suite
Bring the data into your database, but not
is going to log a payment document number for a payment into E-Business Suite.
which didn’t take place in E-Business Suite (hint: auditors don’t
like this).
Create a custom schema (check your licensing arrangements
To address this, a conversion payment document can be set up first) and export/import or SQL*Load the legacy data into tables
(or possibly more than one if you’re migrating multiple historic of the same structure just living in Oracle. This works if you don’t
payment formats, e.g. cheques and EFT). This document and its need to use the data in key processes, but want to have it to
associated sequence numbering is set up solely to simulate a hand for reporting. If you create synonyms for this data in your
payment being made, the payment document could be linked APPS schema then E-Business Suite reporting tools can see it
to your normal and then you can reconcile these transactions in and you can report on it through the concurrent manager. If you
cash management with a reversing journal in GL. This will mean are a Discoverer user you could also extend your end user layer
that you can have a line in cash management with a zero value to encompass the non- E-Business Suite data.
and all the take on payments will be reconciled to this line with
the GL Journal. As an alternative, set up a dummy bank account, Historic data can be valuable, but less so the further back you
just remember to deactivate it afterwards. go (and don’t forget, the data starts ageing as soon as you
load it). There are mechanisms available to get most data
Some Oracle modules are more helpful in the migration of into E-Business Suite in their historic form, but this will make
historic data, for example Service Contracts. We’re involved in a your conversion project more difficult. So the key is to strike
migration using this module currently and there is a very handy the balance between necessary functionality and the safety
feature within the Service Contracts APIs which allows you to net of having lots of data. One thing we found very useful
create a contract as either fully, partially or completely unbilled was to review this balance after the first trial migration, the
at the point of creation. You achieve this via different billing organisation reduced their scope by about 40% when they saw
streams attached to the contracts, remembering to set the fully how long it took to migrate and the total volume of data. In
billed flag on the API call. truth, you probably need less data than you think you do.

ABOUT Michael Lane

Managing Technical Consultant, Claremont
THE Michael is the managing technical consultant for Claremont an Oracle Gold Partner
AUTHOR that provides E-Business Suite consultancy, managed services and hosting. Michael’s
role is to lead the technical delivery of projects for Claremont’s clients as well as
developing new service lines for Oracle Fusion and mobile applications. Michael
has been working with Oracle E-Business Suite since 1994.

www.ukoug.org 33