1. What is the function of the R12 SLA (Subledger Accounting) Pre-Upgrade program?
In order to understand the function of the R12 SLA Pre-Upgrade
program, you must first understand the R12 SLA Upgrade. During the upgrade,
existing accounting data from the subledgers (i.e., AR, AP) is upgraded into
the new Oracle Subledger Accounting (SLA) data model. By default, the upgrade
updates the data for the current fiscal year, as well as the necessary periods
of the previous fiscal year, to ensure that there are at least six periods
included in the upgrade (occurs when the upgrade is performed in the first half
of the fiscal year)--This is the minimum downtime upgrade.
You may need to run the SLA Pre-Upgrade program if you are using
Oracle General Ledger and at least one of the following subledgers: Assets,
Cost Management, Payables, Receivables, Purchasing, or Project Accounting. This
optional program allows you to change the default number of periods of historic
data to be upgraded.
If you do not perform a complete upgrade of the accounting data, Oracle Subledger Accounting allows you to perform an additional upgrade of the data by running the SLA post-upgrade process whenever the missing data is required--see Subledger Accounting in Appendix G of the related documentation:
If you do not perform a complete upgrade of the accounting data, Oracle Subledger Accounting allows you to perform an additional upgrade of the data by running the SLA post-upgrade process whenever the missing data is required--see Subledger Accounting in Appendix G of the related documentation:
R12.1 Oracle Applications Upgrade
Guide: Release 11i to Release 12.1.3 E16342-03
R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4 E12011-02
R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4 E12011-02
The post-upgrade program is executed at the same time as daily
operations. As a result, it may have an impact on overall system performance.
|
Example of
Current Accounting Period on a Calendar Year
|
R12 SLA Down
Time Upgrade Default
|
R12 SLA
Pre-Upgrade Program
|
|
Aug 2008
|
Jan 2008 - Aug 2008
|
Allows you to specify the number of periods
|
|
Feb 2008
|
Sep 2007 - Feb 2008
|
Allows you to specify the number of periods
|
Note: The R12 SLA Pre-Upgrade Program does not perform the
actual upgrade. This program writes out to the GL_PERIOD_STATUSES table. It is
the Subledger (i.e., AP, AR) upgrade programs that actually perform the upgrade
by reading the accounting information in the Subledger tables and writing the
corresponding records to the SLA tables for future reference.
2. When
and how do I run the R12 SLA Pre-Upgrade program?
The R12 SLA Pre-Upgrade program is run on your 11i instance.
In order to run the R12 SLA Pre-Upgrade program to change the default number of
periods of historic data to upgrade, you must apply Patch 5233248 to your Release 11iAPPL_TOP and submit the
SLA Pre-Upgrade Program. See Note
427639.1 for more information.
PROJECTS: If
you use Oracle Projects and/or Grants Accounting, please apply Patch 10231107 on your 11i instance.
Refer to the following release specific documentation for more
information on the SLA Pre-Upgrade program:
R12.1 Oracle Applications Upgrade Guide: Release 11i to Release 12.1.3 E16342-03
R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4 E12011-02
See Chapter 2: The following is an excerpt from this manual:
If you need to change the default number of periods of historic data to be upgraded, you must apply patch 5233248 to your Release 11i APPL_TOP and submit the SLA Pre-Upgrade program. When submitting this program, you can enter the following parameters:
R12.1 Oracle Applications Upgrade Guide: Release 11i to Release 12.1.3 E16342-03
R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4 E12011-02
See Chapter 2: The following is an excerpt from this manual:
If you need to change the default number of periods of historic data to be upgraded, you must apply patch 5233248 to your Release 11i APPL_TOP and submit the SLA Pre-Upgrade program. When submitting this program, you can enter the following parameters:
- Migrate all sets of books: Possible values are Yes (SLA Pre-Upgrade program updates the periods in all sets of books) or No (SLA Pre-Upgrade program updates the periods that belong to the selected set of books).
- Set of books: Set of books to be upgraded where you have selected to upgrade one set of books.
- Start Date: Date to be used to determine the first period to be upgraded. It does not have to be the starting date of a period. The initial period is determined as the first period in which this date falls.
The start date can be changed to a date earlier than the 6 months
minimum, but not shortened to less than the default.
3. What table is updated by the R12
Pre-Upgrade program?
The GL_PERIOD_STATUSES table is updated by this program.
4. What are the different status codes in the
GL_PERIOD STATUSES table?
The MIGRATION_STATUS_CODE column indicates the status of the record
in the GL_PERIOD_STATUSES table.
- P = Pending Upgrade
The system is preparing to upgrade the accounting periods in this table that have a status P. The accounting transactions in these corresponding accounting periods will be upgraded from 11i to R12 by the Subledger products (i.e, AR, AP etc). - U = Upgraded
The accounting records have been upgraded from 11i to R12 - N = New-Only used by GL
= These records do not meet any of the criterion mentioned in Ques 6 and will therefore not be considered in the upgrade.
5. Where can I find information on the GL_PERIOD_STATUSES table?
You can find information about this table via the eTRM (Electronic Technical Reference Manual).
Start by accessing Metalink Note 150268.1. Log into eTRM with your Metalink account. Select Database 12.0, then enter GL_PERIOD_STATUSES in the search field.
6. What criterion does the R12 Pre-Upgrade Program
follow?
The R12 Pre-Upgrade Program tags the accounting periods in the
GL_period_statuses with P for pending upgrade when the following criterion is
met:
- The records are for AP, AR, Project Accounting, FA, Inventory/Costing and PO products only.
Note: No other products are considered by this pre-upgrade
program
- The accounting period under
consideration must be a NON-Adjustment period.
Note: Adjustment periods are not upgraded because the upgrade that was designed by the Subledger Product teams (AP, AR etc) cater to the transactions created by those products and posted to GL. Typically, the Subledger Product teams do not generate transactions that post into adjusting periods. Given that adjusting periods overlap dates with non-adjusting periods, the logic for mapping a transaction into an accounting period is to take the GL date and figure out which non-adjusting period it falls into. - The period has a status of
closed, open, future, and never opened.
Note: Never opened is only applicable to the Inventory/Costing product.
Yes, the R12 upgrade works differently for AP transactions. For AP only, all records in the ap_accounting_events_all, ap_ae_headers_all, and ap_ae_lines_all tables are upgraded into 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.
For all other products, events/headers/lines/and distribution_links are all
migrated based on xla_upgrade_dates and gl_period_statuses.
7. Where can I find the documentation for the R12 Pre-Upgrade Program?
The R12 Pre-Upgrade program is documented in the following manuals:
R12.1 Oracle Applications Upgrade
Guide: Release 11i to Release 12.1.3 E16342-03
R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4 E12011-02
An excerpt of Chapter 2 that discusses the R12 Pre-Upgrade has been attached to this article.
You can also obtain a copy of the complete manual via the OTN portal--Go to the Oracle Applications Documentation > 12.1.3+ or 12+ > select Documentation tab > access the Upgrade Guide 11i to 12.1.3 (or 11i to 12.0.4)
R12.0 Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4 E12011-02
An excerpt of Chapter 2 that discusses the R12 Pre-Upgrade has been attached to this article.
You can also obtain a copy of the complete manual via the OTN portal--Go to the Oracle Applications Documentation > 12.1.3+ or 12+ > select Documentation tab > access the Upgrade Guide 11i to 12.1.3 (or 11i to 12.0.4)
The Application_IDs are used for internal purposes only.
The R12 Pre-Upgrade program considers the following Application IDs--200,222,201,275,401,101
200 = Payables
222 = Receivables
201 = Purchasing
275 = Project Accounting (PA)
401 = Inventory/Costing
101 = Fixed Assets (Fixed Assets uses GL periods)
8721 - Capital Resource Logistics (CRL)
The R12 Pre-Upgrade program considers the following Application IDs--200,222,201,275,401,101
200 = Payables
222 = Receivables
201 = Purchasing
275 = Project Accounting (PA)
401 = Inventory/Costing
101 = Fixed Assets (Fixed Assets uses GL periods)
8721 - Capital Resource Logistics (CRL)
8a. Once I have run the Pre-Upgrade program, can I re-run it with a
different set of dates?
The pre-upgrade program writes to the
GL_PERIOD_STATUSES table. This program does not make any provisions for
resetting the file, even if you run it again with a new set of parameters. See Note
564352.1.
9. Does
the SLA pre upgrade program generate an output file?
The SLA Pre-Upgrade program does not generate an output file. If
the program is successful, then the column MIGRATION_STATUS_CODE would be set
to 'P' in the GL_PERIOD_STATUS table.
9a. Can I run the pre-upgrade program after
completing the R12 upgrade?
You should NEVER run the R12 SLA Pre-Upgrade concurrent program
after you have completed the R12 upgrade as this can cause data issues.
TROUBLESHOOTING THE SLA PRE-UPGRADE PROGRAM
10a. How do I troubleshoot issues with the SLA PRE-UPGRADE PROGRAM?
This information will help you determine what periods the SLA Pre-Upgrade program has selected for upgrading.
select application_id, set_of_books_id,
min(start_date), max(end_date)
from gl_period_statuses
where migration_status_code = 'U'
and adjustment_period_flag = 'N'
group by application_id, set_of_books_id;
SAMPLE OUTPUT
|---------------------------------------------------------------------------|
| APP ID | BOOKS | MIN(START_DATE) |MAX(END_DATE) | Legend for App ID:
| 101 | 1 | 01-APR-10 | 28-FEB-11 | - Fixed Assets
| 200 | 1 | 01-APR-10 | 28-FEB-11 | - Payables
| 201 | 1 | 01-APR-10 | 28-FEB-11 | - Purchasing
| 222 | 1 | 01-APR-10 | 28-FEB-11 | - Receivables
| 275 | 1 | 01-APR-10 | 31-MAR-11 | - Project Accounting
| 401 | 1 | 01-APR-10 | 31-MAR-17 | - Inventory/Costing
|---------------------------------------------------------------------------|
10b. How does the SLA Pre-Upgrade program
determine what is the START DATE and END DATE?
In our example above, the SLA Pre-upgrade picked 01-APR-2010 as its
start date when the client expected
01-SEP-2010, which is 6 months prior to 28-FEB-2011 (which was when the upgrade was run).
START DATE
The SLA pre-upgrade program selects the first date of the current fiscal year as its START DATE.
If there are not enough periods to make up 6 months, then the system will look at the periods in the prior fiscal year.
In the above example, the client's fiscal period began on 01-APR-2010, so the system selected that date.
If the client's fiscal period began on 01-JAN-2011 and the SLA Pre-upgrade was run on 28-FEB-2011, then the program would have chosen 01-SEP-2011 as its start date.
01-SEP-2010, which is 6 months prior to 28-FEB-2011 (which was when the upgrade was run).
START DATE
The SLA pre-upgrade program selects the first date of the current fiscal year as its START DATE.
If there are not enough periods to make up 6 months, then the system will look at the periods in the prior fiscal year.
In the above example, the client's fiscal period began on 01-APR-2010, so the system selected that date.
If the client's fiscal period began on 01-JAN-2011 and the SLA Pre-upgrade was run on 28-FEB-2011, then the program would have chosen 01-SEP-2011 as its start date.
END DATE
The END DATE is the last open period. If you have open the periods for some products and not others, then the end date would differ for each product. In the SAMPLE OUTPUT (10a), the products for Application IDs 401 and 275 had open periods through 31-MAR-2017 and 31-MAR-2011, respectively. The SLA Pre-Upgrade select all open periods in case there are transactions created for future periods.
The END DATE is the last open period. If you have open the periods for some products and not others, then the end date would differ for each product. In the SAMPLE OUTPUT (10a), the products for Application IDs 401 and 275 had open periods through 31-MAR-2017 and 31-MAR-2011, respectively. The SLA Pre-Upgrade select all open periods in case there are transactions created for future periods.
10c. Does the SLA Pre-upgrade
program perform the upgrade?
The R12 SLA Pre-Upgrade Program DOES NOT perform the actual
upgrade. This program writes out to the GL_PERIOD_STATUSES table. It is
the subledger (i.e., AP, AR, FA, Costing etc.,) upgrade programs that actually
perform the upgrade by reading the accounting information in the subledger (FA,
AP, AR etc.,) tables and writing the corresponding records to the SLA tables
for future reference.
Note: The upgrade program works differently for AP. The AP upgrade considers all records in the ap_accounting_events_all, ap_ae_headers_all, and ap_ae_lines_all tables. See question 6a above.
Note: The upgrade program works differently for AP. The AP upgrade considers all records in the ap_accounting_events_all, ap_ae_headers_all, and ap_ae_lines_all tables. See question 6a above.
R12 SLA POST-UPGRADE
To upgrade accounting transactions after you have completed the R12
Upgrade, you can perform the SLA Post-Upgrade Process. In this process, you
will be able to specify a subset of the accounting and tax data to
upgrade.
See Appendix G of the Oracle Applications Upgrade Guide for more
information on this process. See Ques 2 for the link to the documentation that
is specific to the release you have.
You can run the SLA hot patch during uptime to upgrade historical
data, if you only did a partial or minimal upgrade during downtime.
OR
You can run the "Upgrade Historical Subledger Transaction Accounting Program", which was first introduced in R12.1.2 (Doc 973404.1)
OR
You can run the "Upgrade Historical Subledger Transaction Accounting Program", which was first introduced in R12.1.2 (Doc 973404.1)
12a. How do I
run the SLA Hot Patch or SLA post-upgrade process?
Before running any SLA post-upgrade process (i.e., SLA Hot Patch),
you must enter the initial date to be used to determine the initial period to
be upgraded. This date is entered in the SLA: Initial Date for Historical
Upgrade profile option. This profile option must be populated in order to
run the process.
Run the process as follows:
1.Run AutoPatch with options=hotpatch.
2.Specify $XLA_TOP/patch/115/driver/xla5584908.drv when prompted for the unified driver.
Note: The SLA Hot Patch can be run multiple times, each time by specifying a date that covers a range that has not been upgraded.
For example, if your current fiscal year starts on 1-Jan-2008 and the current date is 1-Oct-2008, and you did not run the pre-upgrade process, then financial data for all your periods from Jan-08 to latest future open period will be upgraded during Downtime upgrade.
Run the process as follows:
1.Run AutoPatch with options=hotpatch.
2.Specify $XLA_TOP/patch/115/driver/xla5584908.drv when prompted for the unified driver.
Note: The SLA Hot Patch can be run multiple times, each time by specifying a date that covers a range that has not been upgraded.
For example, if your current fiscal year starts on 1-Jan-2008 and the current date is 1-Oct-2008, and you did not run the pre-upgrade process, then financial data for all your periods from Jan-08 to latest future open period will be upgraded during Downtime upgrade.
In the diagram above, data from Jan 2008 to current has been
upgraded. To upgrade data from Jan 2004 to current, then do the following:
a. Change the SLA: Initial Date for Historical Upgrade profile
to 01-Jul-2007
b. Then run the Hot Patch
c. Repeat the above steps for 6-month increments until all the data from Jan 2004 has been upgraded. The 6-month increment is not a rule because it really depends of the amount of history that is available to be upgraded.
Note: Running the Hot Patch could take several minutes or several hours to complete depending on the date range you specify and the amount of data to be upgraded.
b. Then run the Hot Patch
c. Repeat the above steps for 6-month increments until all the data from Jan 2004 has been upgraded. The 6-month increment is not a rule because it really depends of the amount of history that is available to be upgraded.
Note: Running the Hot Patch could take several minutes or several hours to complete depending on the date range you specify and the amount of data to be upgraded.
12b. Where can I find information about the
concurrent program "Upgrade Historical Subledger Transaction
Accounting" - XLAONDEUPG?
See [Document 980112.1] for detailed information on this concurrent
program.
13. Are there any restrictions when running the
SLA Hot Patch?
Yes, there are some restrictions. They are as follows:
(a) You cannot run the SLA Hot Patch for a period that is included in the range already upgraded.
For example, in the diagram under Ques 12 where it is assumed that the data for Jan 2008 up to the current accounting period has been upgraded, you cannot enter a date of Sep 2008 to rerun the upgrade.
(b) You cannot run the SLA Hot Patch if any period is pending upgrade, even if it only affects one of many applications. See Ques 4 above for an explanation on the different status codes.
(a) You cannot run the SLA Hot Patch for a period that is included in the range already upgraded.
For example, in the diagram under Ques 12 where it is assumed that the data for Jan 2008 up to the current accounting period has been upgraded, you cannot enter a date of Sep 2008 to rerun the upgrade.
(b) You cannot run the SLA Hot Patch if any period is pending upgrade, even if it only affects one of many applications. See Ques 4 above for an explanation on the different status codes.
(c) You cannot run the Hot Patch for one ledger or one application
(i.e., AP or AR).
(d) You cannot run the Hot Patch for open transactions only. The
upgrade looks at the start and end period, and it upgrades ALL transactions
within the date range. The GL Headers that are created for these transactions
are tagged as Upgraded and so are the periods.
13a. Where can I find detailed
instructions for the SLA Post-Upgrade and do I have to apply any additional
patches?
Detailed instructions for the SLA Post Upgrade (aka SLA Hot Patch)
can be found in Note: 751160.1
There are NO additional patches required for R12.0 or R12.1
GENERAL QUESTIONS
This is the technical flow of the R12 SLA Upgrade, which is performed in the main r12 udriver file.
- Identify what accounting
periods will be upgraded. The periods to be upgraded depend upon the
minimum Downtime upgrade or initial period setup in the pre-upgrade or
uptime upgrade.
Files Used: XLA_UPGRADE_DATES and GL_PERIOD_STATUSES - The periods to be upgraded
are stamped with an intermediate status (P-pending).
The same set of periods are populated in the XLA_UPGRADE_DATES. - The data in the Subledger
accounting tables are upgraded into the SLA accounting tables.
The periods in the XLA_UPGRADE_DATES is checked in this step. - The Subledger products call the SLA API to update the period status column in the General Ledger. They stamp the data for the periods specified to indicate that they have been upgraded (U-upgraded).
- The SLA API stamps the
GL_JE_HEADERS table for the upgraded applications.
The column je_from_sla_flag=U is also stamped. - This completes the R12 SLA Upgrade cycle.
15. What pre-cautionary steps should I take "BEFORE" performing the R12 SLA Upgrade?
(a) If you are upgrading or implementing R12.0.5 Patch 6836355 or R12.0.6 Patch 6728000 apply Patch 8234812 before you start the R12 upgrade. This
was a regression that was introduced in R12.0.5 and R12.0.6 in Feb.
(b) It is good practice to transfer or post all 11i data from your
respective subledgers (i.e., AP, AR, FA, etc.,) to the General Ledger before
running the Downtime upgrade.
(c) You can post data after going live; however, you should avoid, if at all possible, having 11i accounted data that has not been transferred prior to upgrading. If for some reason this situation cannot be avoided, please refer to the Note 747237.1 R12 SLA: What is the role of GL_SL_LINK_ID in R12 and 11i?
(c) You can post data after going live; however, you should avoid, if at all possible, having 11i accounted data that has not been transferred prior to upgrading. If for some reason this situation cannot be avoided, please refer to the Note 747237.1 R12 SLA: What is the role of GL_SL_LINK_ID in R12 and 11i?
16. What should I verify from
an SLA Upgrade standpoint after the downtime R12 upgrade and/or SLA Hot Patch
is run?
a. Verify that there are no periods pending upgrade in the GL_PERIOD_STATUSES
table, after the R12 upgrade or SLA Hot patch is run. See Note
747216.1 R12 SLA Upgrade: Check that the SLA Pre-Upgrade Completed
Successfully.
b. Compare the AP Trial Balance outputs from 11i to that in R12.
You only need to check this after the downtime R12 upgrade and NOT after any
SLA Hot Patch execution. Technical tips can be found in Note:
605707.1 SLA: Troubleshooting the AP to GL Reconciliation, see
Questions QR1 through QR12.
17. What pre-cautionary steps
should I perform "BEFORE" running the SLA Hot Patch?
a. Run this SQL script:
select * from gl_period_statuses where migration_status_code='P'
-- this script should return zero rows, only then should you consider running the SLA Hot Patch.
b. Take a backup of the xla_upgrade_dates table before running the SLA Hot Patch
c. Set a realistic date for the SLA: Initial Date for Historical Upgrade profile. Do not set a date like 1-Jan-1900 or 1-Jan-1000.
select * from gl_period_statuses where migration_status_code='P'
-- this script should return zero rows, only then should you consider running the SLA Hot Patch.
b. Take a backup of the xla_upgrade_dates table before running the SLA Hot Patch
c. Set a realistic date for the SLA: Initial Date for Historical Upgrade profile. Do not set a date like 1-Jan-1900 or 1-Jan-1000.
18. Where is my accounting data
stored in R12 and how does it differ than 11i?
In R12, the SLA tables hold the accounting data for all the
Subledger products. As a result you may see a significant increase in the size
of the SLA tables. In R12, we also retain the distribution level accounting
details that is stored in XLA_DISTRIBUTION_LINKS.
In Release 11i, the accounting data was stored in individual Subledger (i.e., AP, AR, FA) accounting tables. Also, in 11i, we did not retain the distribution level accounting details. These tables are no longer used in R12.
In Release 11i, the accounting data was stored in individual Subledger (i.e., AP, AR, FA) accounting tables. Also, in 11i, we did not retain the distribution level accounting details. These tables are no longer used in R12.
19. Are there any known issues?
The known issues are highlighted below:
R12.0.5 and R12.0.6 Regression
A regression was introduced in R12.0.5 and R12.0.6. As a result of this regression, any customer who has upgraded may not be able to run the SLA hot patch, at a later time. Apply the pre-install critical Patch 8234812 to correct the problem.
A regression was introduced in R12.0.5 and R12.0.6. As a result of this regression, any customer who has upgraded may not be able to run the SLA hot patch, at a later time. Apply the pre-install critical Patch 8234812 to correct the problem.
SLA Hot Patch
Cannot run the SLA HOT Patch after upgrading from 11i to R12.0 or R12.1 because the LAST_UPDATED_BY field in the GL_PERIOD_STATUSES table has a -601 or -602. This is related to Bug 11829821. This patch is an upgrade patch and is only applicable to users who have not already upgraded from 11i to R12.0 or R12.1. A data fix is required to correct the data in the GL_PERIOD_STATUSES table. Please log a service request with Oracle Support to request the data fix.
Cannot run the SLA HOT Patch after upgrading from 11i to R12.0 or R12.1 because the LAST_UPDATED_BY field in the GL_PERIOD_STATUSES table has a -601 or -602. This is related to Bug 11829821. This patch is an upgrade patch and is only applicable to users who have not already upgraded from 11i to R12.0 or R12.1. A data fix is required to correct the data in the GL_PERIOD_STATUSES table. Please log a service request with Oracle Support to request the data fix.
Receivables
Customers get an error while running the SLA Hot patch. The adpatch log shows that ar120girpu.sql failed. Customers who encounter this issue should log a service request with the Receivables team and request a datafix. Ref. Bug 9071674.
Customers get an error while running the SLA Hot patch. The adpatch log shows that ar120girpu.sql failed. Customers who encounter this issue should log a service request with the Receivables team and request a datafix. Ref. Bug 9071674.
Project Accounting
PA customers get ORA-20500: There are periods pending upgrade for Application ID 8721 even though the customer has not enabled Enhanced Period Processing (EPP). The problem is that the SLA post upgrade cannot be run when attempting to run the SLA Hot patch. Customers who encounter this issue, should log a service request with the Project Costing team to request a datafix.
Ref. Bug 8582427
PA customers get ORA-20500: There are periods pending upgrade for Application ID 8721 even though the customer has not enabled Enhanced Period Processing (EPP). The problem is that the SLA post upgrade cannot be run when attempting to run the SLA Hot patch. Customers who encounter this issue, should log a service request with the Project Costing team to request a datafix.
Ref. Bug 8582427
GLOSSARY OF TERMS USED
Downtime: This is when the R12 upgrade program is run when the
system is taken down and not available to the end-users.
Uptime: This is when the system is operational and available to end users after the R12 Upgrade has completed.
SLA Hot Patch: This is a patch that can be applied to your R12 instance, while the system is up and running (during uptime). It is a patch that can be run as part of the Post-Upgrade process.
Pre-Upgrade Process: See the excerpt from the Oracle Applications Upgrade Guide: Release 11i to R12
Uptime: This is when the system is operational and available to end users after the R12 Upgrade has completed.
SLA Hot Patch: This is a patch that can be applied to your R12 instance, while the system is up and running (during uptime). It is a patch that can be run as part of the Post-Upgrade process.
Pre-Upgrade Process: See the excerpt from the Oracle Applications Upgrade Guide: Release 11i to R12
Post-Upgrade Process: See an excerpt from Oracle Applications
Upgrade Guide: Release 11i to R12
BUG:11829821 - LAST UPDATE BY CHANGE TO A INVALID VALUE AFTER UPGRADE
BUG:7159377 - SLA PRE-UPGRADE PROGRAM UNABLE TO SELECT ALL RECORDS
BUG:7161091 - JOURNAL LINE DRILLDOWN FEATURE ERRORS SOCKET TIMEOUT
BUG:7192502 - SUBSET OF 11I SUBLEDGER TRANSACTIONS ARE MISSING IN THE R12 XLA TABLES
BUG:7202005 - ISSUE ON UPGRADE TO R12.0.4 SLA PREUGRADE PROGRAM
BUG:8355206 - SLA UPGRADE: HOW IS IT SUPPOSE TO WORK
NOTE:1127593.1 - R12.1: Oracle Financials Pre-Upgrade Patch -- Supplemental List for EBS CUP
NOTE:399362.1 - Oracle Applications Release 12 Upgrade Sizing and Best Practices
NOTE:427639.1 - SLA Pre-Upgrade Program Is Not Enabled
NOTE:549682.1 - Subledger Upgrade Defaults For One Year - How Can This Be Set to Six Months Instead?
NOTE:564352.1 - Run The SLA-Pre Upgrade Program Once-Can We Run It Again With A Different Date Range
NOTE:739187.1 - R12 No Upgraded Data in XLA_EVENTS table for Projects and/or Grants Accounting
NOTE:740586.1 - Oracle Applications Upgrade Guide: Release 11i to Release 12.0.4
NOTE:954704.1 - EBS: R12.1 Oracle Financials Recommended Patches
NOTE:973404.1 - Oracle Subledger Accounting Release Notes, Release 12.1.2
NOTE:980112.1 - New Functionality for SLA Upgrade Process for R12.1.2
