Wednesday, May 22, 2013

R12 Upgrade - Options for upgrading your historical data to Subledger Accounting Model (SLA)



If you are currently on Oracle EBS 11i (Financials or Order to Cash or Procure to Pay),  what options do you have for upgrading your historical data in 11i to Subledger Accounting Model? Hope this posting will clarify your questions.

First of all, let us understand what will 11i Upgrade process do with your Subledger Data.

By Default, it will upgrade 6 months of data. But the fact is, it is not always 6 months. Here is an example of how much data will be upgraded to the SLA model by default.



If you have more than six months of data in the current open fiscal calendar year, the current fiscal calendar start date is taken as the default start date for SLA conversion. If you have less than 6 months of data in the current open fiscal calendar, Upgrade automatically converts 6 months from the day the upgrade is run.

Also, it is really interesting to note that the entire AP data is converted to SLA model by default. Basically all your data from ap_accounting_events_all, ap_ae_headers_all and ap_ae_lines_all are upgraded to the respective SLA tables. Only the xla_distribution_links records for AP are migrated based on the xla_upgrade_dates and the accounting period in the gl_period_statuses tables.

So, what are your options to convert the rest of the data to SLA Data model? Hopefully the following picture will explain it all.


 So, you have a few options for upgrade

You can leave the default option or do a Pre-Upgrade or do a Post-upgrade using Hot Patch with Default or do a Post-upgrade using Concurrent Program (XLAONDEUPG) along with Default.

If you are using Project Accounting module and you are planning to convert the PA data to SLA datamodel, then you can't use the option 4 above. SLA: Upgrade Historical Subledger Transaction Accounting Program is not compatible with Project Accounting module.

On the other hand, there a lot of advantages with using the option 4. You can run this program by product, ledger or period. This gives a lot of flexibility to upgrade your historical data post-upgrade. Also, since this is run after the upgrade is completed, the actual upgrade time can be conserved.

If you are using Project Accounting module and would like to convert your entire PA data to SLA model, you have no option but to choose Option 2 or 3.  Option 3 is probably the best bet because, you are not forcing yourself to converting the entire data in one-go that too during upgrade like Option 2.  Here is a picture representing the various options you have to convert your SLA data during Upgrade.




 At the end of the day, it is upto your project strategy team to decide which option to choose from. None of the business users will be happy with Option A for sure.

16 comments:

  1. Hi Lakshmi,
    Great post! Thanks for the information. I have a question regarding Purchasing. Under what circumstances should I see Purchasing history in the XLA_AE tables after the Hot Patch method is run? We do not use Encumbrances. I ask because my company ran the Hot Patch and I do NOT see any records for APPLICATION_ID = 201 in the XLA_AE tables.

    Appreciate any input.

    Thanks,

    Peter

    ReplyDelete
    Replies
    1. Peter,

      Thanks for the feedback.

      Before you run the hot patch, did you set the Profile option to set the dates back to the historical date (older than the default period) ?

      Run the following query to check what is the date that is set for the above profile option

      select application_id, set_of_books_id,
      min(start_date), max(end_date)
      from apps.gl_period_statuses
      where migration_status_code = 'U'
      and adjustment_period_flag = 'N'
      and application_id = 201
      group by application_id, set_of_books_id;

      The date retrieved by this query should match the Profile Option date you have set.
      If so, Your hot patch is successful.

      Also, when the data is transferred from Purchasing to SLA layer, it usually transfers with Cost Management application id.

      Run the following query

      select * from apps.xla_ae_headers
      where application_id =707;

      This should give you all the transactions that have been converted.

      Let me know if you have more questions,

      Thanks
      Lakshmi

      Delete
    2. we are providing details about Oracle Fusion Procurement training.
      and other all training institutions details

      http://www.calfre.com/Hyderabad/Oracle-Fusion-Procurement-Training/listing

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Hello Lakshmi,

    The first query returns a 2002 date and the profile set by DBA or other financial team was a 2004 date.

    The second query returns no rows.

    The only way I can get data into XLA Headers and Lines is by running the Period End Accrual process and then Create Accounting - Receiving. That seems to pump in all history but with a current accounting date.

    We do not use encumbrances and there are no Accrual Write Off accounts setup.

    Is this correct or is there a problem?

    Appreciate all your input.

    Thanks,
    Pete

    ReplyDelete
    Replies
    1. Hello Peter,

      This certainly seems like a issue to me. Open an SR with Oracle and find out why hot patch is not converting the data into SLA model for you.

      I will let you know if i think of more information.
      Thanks
      Lakshmi

      Delete

    2. Peter,

      Just a thought. Do you have all the pre-requisite patches applied before running the hot patch?

      Refer to the metalink note :
      Mandatory patches before running SLA Hot Patch [ID 1460065.1]

      Make sure the costing patches are included in yours as well.

      Thanks
      Lakshmi


      Delete
  4. Hi Lakshmi,

    My team applied these patches per oracle, set the system profile for the SLA history Date, and did the hot patch.
    11854288:R12.XLA.B
    13978746:R12.AP.B
    12578648:R12.AP.B
    12650984:R12.AR.B
    13598940:R12.AR.B
    13055635:R12.FA.B
    13815017:R12.BOM.C
    13509912:R12.PJC.B
    12372035:R12.ZX.B
    12648752:R12.ZX.B
    8671363:R12.ZX.B

    I opened an SR with Oracle and they advised to run Upgrade Historical Subledger Transaction Accounting under Cost Management - SLA.

    We did and I do not see records in the XLA_AE tables for APP ID 201 (purchasing) or 707
    (cost mgt). I updated the SR with oracle.

    We shall see. Thanks so much!

    Pete

    ReplyDelete
  5. Hi Pete,

    Thanks for the update.

    Hot Patch and Upgrade Historical Subledger Transaction Accounting program are incompatible with each other . Can you ask Oracle Support why they suggested you to run this program since you have already run the hot patch before?

    thanks
    Lakshmi

    ReplyDelete
  6. Hi Lakshmi,

    Can you kindly confirm if we still need to run Upgrade Historical Subledger Transaction Accounting program for Accounts Payable subledger becuase with the default run of six months it has already converted Accounts Payble module but i don't know if the conversion is complete or do we still need to run this program if we are running this program for other subledger modules.

    Thanks

    Vipul Mehta

    ReplyDelete
  7. Vipul

    With the default run of six months, it only converts 6 months of AP data.

    Basically this is what happens during upgrade- Eventhough it converts all the AP data to sub-ledger accounting model, the xla_distribution_links will be populated only to link 6 months of data.

    You have to run either the SLA Hot Patch or the Upgrade Historical Subledger Transaction Accounting program to convert the rest of the data.

    Hope this helps.

    Thanks
    Lakshmi

    ReplyDelete
  8. Hi Lakshmi,
    Great article on how to convert and check the conversion, can you please elaborate on the needs to convert?
    One common reason I see across is performing activity on upgraded transaction, are there any other reasons why one need to convert historical data to SLA tables?

    Also how does this impact GL Drill down and the way data is stored in GL_import_references for historical and new transactions?

    Thanks

    ReplyDelete
  9. Hi Lakshmi,
    Great article, thanks a lot for sharing the information to everyone with your expertise. Could you please let me know if there anything specific to HRMS modules for release 11i to 12.1.3 upgrade.

    Thanks,
    Sridhar

    ReplyDelete
  10. Hi Lakshmi,
    At a client where we are upgrading from 11i to 12.2.5, they have 17 yrs worth of 11i data. If we run the SLA post upgrade program to get data only for 3 yrs, then what will be the impact for the remaining 14 yrs. I am assuming drilldown will not work for any Journal that originated from a sub-ledger transaction that was 4 or more yrs old. What are any other impacts of not running the upgrade?

    ReplyDelete
  11. Hi Lakshmi,

    Thanks for the post and can you please clarify one point on option 4. You mentioned that if you are using Project Accounting module and you are planning to convert the PA data to SLA datamodel, then you can't use option 4 above.

    Does it mean that this program should not be used for converting PA data or it should not be used if PA is implemented within the environment? If Projects is implemented can I used this program AP data upgrade?

    Regards,
    Sunil

    ReplyDelete