“As part of Oracle’s continued commitment to our customers, we will be providing an exception for the first 13 months of Sustaining Support on Oracle E-Business Suite Release 11.5.10 (11i10), valid from December 1, 2013 – December 31, 2014. This exception support will be comprised of three components:
(1) new fixes for Severity 1 production issues,
(2) United States Form 1099 2013 year-end updates, and
(3) payroll regulatory updates for the United States, Canada, United Kingdom, and Australia for fiscal years ending in 2014.
In addition, the Extended Support period for E-Business Suite Release 12.1 has been extended through December, 2018. Customers with an active Oracle Premier Support for Software contract will automatically be entitled to Extended Support deliverables for E-Business Suite 12.1.”
When upgrading to 12.1.1 and then 12.1.3, if you don’t apply patch 5233248 during the application of your 11i patches to prepare your database objects for R12, after the upgrade and all the R12.1.3 patches have been applied, there are three invalid objects that can only be resolved by applying this SLA patch to the 11i instance, in advance of the upgrade to R12.1.3. This patch is recommended as a patch needed if you are using “Upgrade by Request”. There are other methods to implement “Upgrade by Request”, but this is the method we recommend. If you don’t apply this patch and set the start and end dates with the SLA pre-upgrade program shown below, then only the default number of periods will be upgraded. The number of periods that are upgraded by default are six, unless you set the periods in the SLA pre-upgrade program. We highly recommend setting the starting period to the first period in your instance and the ending period to the last period in your instance.
First, enable the SLA pre-upgrade program:
If you plan to upgrade all your data during the upgrade, and I highly recommend upgrading all your data during the upgrade downtime window, you will need to set the start and end dates for all the GL periods in your instance. Set these dates using the “SLA pre-upgrade” concurrent program as follows:
If you decide to use less than all the GL periods, the amount of time this saves has been about one to two hours during our customers production upgrades. The post upgrade concurrent request can upgrade any remaining data in a few hours, if you choose not to upgrade all your GL periods during the original production downtime window. But a downtime window for this post upgrade concurrent program should requested because of the amount of archive logging it creates. If you have a downtime window to process the remaining GL periods, archive logging can be disabled. If you do not have a downtime window during the post SLA processing, the archive log mount point can fill up and hang your database. For this reason we strongly recommend disabling archive logging during any post processing of SLA data.
This XLA patch needs to be run with 11i patches in order to avoid these three invalid objects after the 12.1.1 / 12.1.3 upgrade: