Description
This appendix covers the following topics:
This appendix contains upgrade verification tasks for the Oracle Customer Relationship Management (CRM) product family.
These tasks apply only to Oracle Email Center.
After the upgrade, all email accounts except INTENT should be available. You can verify these accounts from the Email Center Administrator console screens in the upgraded environment. Administrators should plan to update the account properties and activate accounts as needed.
In addition, administrators should log in as a supervisor and verify that email messages from the live queues and Inbox can be viewed and replied to.
You can use the Email Center migration screens to monitor the status of the message migration process. In case of error, the screen displays descriptive error messages. You should act on each message as required. In case of environment issues during the migration, you can re-run messages selectively.
These tasks apply only to Oracle Incentive Compensation.
Verify that the concurrent requests to generate collection and formula packages have been completed. Verify that the classification packages, collection packages, and formula packages are successfully generated and valid. If needed, regenerate these packages before using the product.
If your system uses external modules, ensure that the following integration points are still valid:
Order Management
Accounts Receivable
Accounts Payable
Oracle Payroll
Territory Manager
These tasks apply only to Oracle Marketing.
From the Campaign workbench, verify that the header information and the mid-tabs were migrated as expected. From the Activity workbench, verify that the header information and activities with different channels (like Email, Fax, Advertising, and Telemarketing) were migrated as expected.
In addition, on the Additional Information mid-tab, turn on the deep links using OA Personalization, and verify that the associations are correct
These tasks apply only to Oracle TeleService.
Perform the following basic functions the ensure that the application is working as expected:
Create a service request. If eAM is implemented, create an eAM service request as well.
Update a service request, including one that was created before the upgrade.
If you are using Charges, ensure that you can create charges lines and submit them to Order Management.
View a service request report.
These tasks apply only to Oracle Territory Manager.
To ensure that the upgrade to Role-based Access Control (RBAC) is complete, verify the following for your users:
All have Territory Management responsibility
All have access to the correct Territory functions
All have access to the correct usage(s)
The named account type should exist by default. If the system contained geographical territories in 11i, there should be a geography type available with the enabled geographical matching attributes from 11.5.10. For non-geographical and non-named account territories that existed in 11.5.10, there should be a general <usage> type that contains all the enabled matching attributes.
Territories mapped from 11i should show the appropriate territory type and should have an end date defaulted to +10 years from the start date if the territory did not previously have an end date. In addition:
All resources should have a transaction access level set to Full.
Self-service geographic territories are visible in the administrator territory hierarchy view, but administrators cannot modify them. All modifications must be made through the self-service UIs.
Resources on escalation territories should be on the territory that the escalation territory was created for, with the resource access set to Escalation.
These tasks apply only to Oracle Advanced Global Intercompany System.
You should review the Advanced Global Intercompany System organizations to ensure that each organization is assigned to a legal entity. In some cases, the automatic upgrade may not identify a single legal entity to associated to any intercompany organization. In that case, the organization is inactivated and you must update it with the correct legal entity before using it in transactions.
These tasks apply only to Oracle Assets.
You should run selected reports and run some online inquiries both before and after the upgrade to verify that your data has no discrepancies.
Run the following reports prior to the upgrade in the Release 11i environment, and then again after the upgrade in the new environment. Compare the results to see if there are any discrepancies. You can run the reports for past periods or for a range of past periods or for the current period as applicable. However, it is important to note that when choosing the periods, you should choose only those that are within the range of periods that you ran the upgrade for.
Cost Summary Report
CIP Summary Report
Reserve Summary Report
Revaluation Reserve Summary Report
Asset Additions Report
Asset Retirements Report
Asset Transfer Report
Asset Transfer Reconciliation Report
Asset Reclassification Report
Asset Reclassification Reconciliation Report
You should also run the Account Drill Down Report in a Release 11i environment and the Account Analysis Report on the same set of data and compare the results.
In your Release 11i environment, go to Inquiry > Financial Information and query a few assets. Click Books > Transactions, then go to Tools > view Accounting. Make sure you are looking at the accounting for transactions that happened in the current fiscal years.
In the new environment, use the same menu path and perform an online accounting inquiry for the same assets and transactions and compare the results. Note that in this release, the menu path takes you to the Oracle Applications Framework page.
These tasks apply only to Oracle E-Business Tax.
To ensure that transaction tax information has been correctly upgraded, run the Payables Tax Audit Trail report and the Receivables Tax Reconciliation report for the current tax period before the upgrade to set a benchmark of transaction information.
Then immediately after the upgrade, run the same reports in the new environment for the same period and compare the results to ensure that the tax values are still the same.
For a sample of Payables and Receivables transactions, record the details of the associated tax for these transactions before migration, and then query them again after the upgrade to ensure that the tax has been correctly upgraded.
Duplicate the same transactions and re-trigger to ensure that the new E-Business Tax-based calculation is consistent with the previous calculation.
These tasks apply only to Oracle Financials for the Americas.
For occurrences that were already posted to the General Ledger prior to the upgrade, verify that the journal entries created in Subledger Accounting are synchronized with those created in General Ledger.
For occurrences that were not yet posted to General Ledger prior to the upgrade, run the Create Accounting program in draft mode (for the Receivables application and the Brazilian Bank Collection Occurrence Documents and Standard Receipts process category codes) to verify that the Subledger Accounting journal entries are created in the same way as they would have been in Release 11i.
These tasks apply only to Oracle Financials for India.
Verify the following sampling of reports (standard and customized), both before and after the upgrade and migration of data. Compare the data in the reports for accuracy.
The list of standard reports includes:
PLA Register Report
RG 23 Reports
RG 23D Reports
Cenvat Monthly Reports
RG-I Report
TDS Reports (Certificates and Returns)
Service Tax Reports
VAT Reports
In addition, run the Income Tax Act Fixed Assets Schedule and Depreciation Detailed Report.
These tasks apply only to Oracle General Ledger.
Run the Accounting Setup Manager Pre-update Diagnosis report prior to the upgrade and the Post-update Diagnosis report after the upgrade in the Standard Request Submission form in a General Ledger responsibility.
The diagnosis includes the following areas:
Sets of Books: Review Sets of Books to be Upgraded to Secondary Ledgers
Multiple Reporting Currencies: Unassigned Reporting Sets of Books
Multiple Reporting Currencies: One Reporting Set of Books Assigned to Multiple Primary Sets of Books
Multiple Reporting Currencies: Reporting Sets of Books With Translated Currencies
Multiple Reporting Currencies: General-Ledger-Only Journal Conversion Rules
Multiple Reporting Currencies: Inconsistent General Ledger Journal Conversion Rules
Multiple Reporting Currencies: Inconsistent Setup
Multiple Reporting Currencies: Incomplete Setup
Review the report and verify that the changes suggested by the Pre-upgrade report were actually performed during the upgrade process.
As a good practice, you should compare financial data and balances before and after the upgrade. Oracle recommends that you submit common reports, such as the Account Analysis, Journals reports, Trial Balance report, and Financial Statements to compare balances and journals before and after the upgrade to ensure that the data was properly upgraded.
The following tasks apply only to Global Accounting Engine.
You should run the Global Accounting Engine accounting reports before the upgrade and the corresponding Subledger accounting reports after the upgrade to ensure that you have a proper audit trail of the upgraded accounting data. The reports are as follows:
| Global Accounting Engine | Subledger Accounting |
|---|---|
| Daily Journal Book | Daily Journal Report |
| Account Ledger by Account | Account Analysis Report |
| Supplier and Customer Subledger by Account | Third Party Balances Summary |
| Supplier and Customer Balance by Account | Third Party Detail and Balances Report |
These tasks apply only to Oracle iProcurement.
In the iProcurement post-upgrade interface, you can see the data exceptions report and the list of newly created global blanket agreements by choosing the Configuration tab from the iProcurement Catalog Administration responsibility. Under Configuration, the Release 12 Upgrade Summary continues two tabs: Exceptions and New Agreements.
Any data listed in the data exceptions report under the Exceptions tab is not available in iProcurement. To fix data issues, follow these steps:
Download the XML file, if available in the exceptions report.
For the upgrade process, the XML file can be downloaded for any error condition in the data exceptions report. There is one compressed file for each supplier/supplier site/contract/language combination. Within the compressed file, there may be multiple files for the action SYNC per each language in which data is available. The file name is ItemException_language.xml.
Fix any data that appears in the downloaded file.
Create or find a global blanket agreement (GBPA).
You must load the content of the file into a GBPA. See the Upload feature in Oracle iProcurement Implementation and Administration Guide for more information on uploading content to a GBPA.
Note: The upgrade data exceptions report is permanent. That is, even if you load the data into GBPAs with the XML file provided, you will continue to see the exception listed in the report.
The upgrade automatically validates and approves all newly created GBPAs. Buyers have access to these agreements through Oracle Purchasing and requesters can search for the content of these agreements in Oracle iProcurement.
The New Agreements tab lists GBPAs based on contract purchase agreements (CPAs). You can see the CPA number used as source data in the GBPA header and the resulting GBPA numbers in the CPA attachment section. See Oracle Purchasing User's Guide for more details on these documents.
For the content zones created as a result of the 11.5.9 and 11.5.10 migration, the upgrade uses the catalog name as the content zone name. To maintain responsibility and operating unit level access restrictions, multiple instances of content zones with the same catalog name may be created.
The Stationery Supplies store contains a Local Catalog consisting of items from Supplier A.
A responsibility-level category realm exists such that users of the US Requesters responsibility can only access items of the Office Supplies category.
The Stationery Supplies store continues to exist and contains two content zones, both of which are named Local.
One of the two Local content zones is configured to contain only items of the category Office Supplies, and is made accessible to the iProcurement responsibility.
The other Local Content Zone is configured to contain all catalog items, and is made accessible to all responsibilities in iProcurement, Purchasing, iSupplier Portal, and Enterprise Asset Management, except the US Requesters responsibility.
After running the upgrade script, check the Manage Content Zones screen in the e-Content Manager. It is possible that some catalogs have not been upgraded completely. In those cases, a warning icon is displayed next to the content zone name.
Note: Any content zone displayed with a warning icon requires further manual configuration before it will function properly.
In this release, content security restricts the number of suppliers, supplier sites, and categories that can be used in defining a content zone. A 2000 byte limit exists for performance concerns. In Releases 11.5.9 and 11.5.10, you could configure local catalogs to include up to 300 specific suppliers. During the upgrade process, iProcurement determines if the number of catalog restrictions for a given catalog can be translated into a string of less than 2000 bytes. When this is possible, iProcurement migrates the catalog into the new content zone(s) completely and automatically. No further user action is necessary.
When a string of 2000 bytes cannot fully encompass the scope of catalog restrictions for a given catalog, iProcurement is not able to migrate the entire catalog completely into the content zones. When this happens, a warning icon is displayed next to the content zone(s) on the Manage Content Zone screen.
In the following example, you must manually divide the list of suppliers and categories restrictions into two or more content zones.
Suppose a “Stationery Supplies” store contains a single local catalog named “Local.” The catalog contains a selection of several suppliers. During the upgrade process, iProcurement cannot translate all specific suppliers into a single content zone because of its 2000 byte limit, so a warning icon is displayed next to the “Local” content zone in the Manage Content Zones screen.
In order to retain the shopping behavior requesters experienced in iProcurement, a Catalog Administrator must manually remove some of the 300 suppliers referenced in the “Local” content zone and create a second content zone to include those suppliers. Both of these content zones can be included in the “Stationery Supplies” store.
These tasks apply only to Oracle Legal Entity Configurator.
You should perform a review of all legal entities and establishments in your system after the upgrade is complete to ensure that the correct legal structure is in place. You can access this information by using the Search Page in the Legal Entity Configurator.
You can find detailed information about the assumptions made during the migration and the data migrated from country-specific fields in the Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12.
If you need to create or upgrade legal entities and establishments, then see the Oracle Financials Implementation Guide for instructions.
These tasks apply only to Oracle Payables.
In your Release 11i environment, run the Accounts Payable Trial Balance, Posted Invoice Register, and Posted Payment Register reports. After the upgrade, run the Open Account Balances Listing Report, Posted Invoice Register, and Posted Payment Register in your upgraded environment and compare the results.
Note: The reports run for a ledger or a ledger set, not within the context of a single operating unit. The Release 11i Trial Balance and Posted Invoice and Payment Registers run within a single operating unit. Depending on your system configuration, you may need to sum several of the 11i reports to tie to the new versions.
To verify the integration with Oracle Payments and the upgrade of existing invoices, submit a payment batch with limited selection criteria in order to pay a few invoices.
Recommended Payables testing includes, but is not limited to the following:
Test Business Scenarios
Pay an upgraded unpaid invoice
Void an upgraded payment
Cancel an upgraded invoice
Apply an upgraded prepayment to a NEW invoice
Unapply an upgraded prepayment from an upgraded invoice
Cancel an upgraded prepayment invoice
Create a new Invoice
Pay a new Invoice
Pay a group of new invoices in a Payment Process Request
Payables Performance
Review Payables Reports
Note: Review EBS R12: Financial Reports impacted by the R12 (12.0 and 12.1) Upgrade (Doc ID: 1110684.1).
Run the Create Accounting process for various volumes of data and verify it completes in appropriate amount of time based on environment ran on and volume of data.
Run the Account Analysis Report for different account and date ranges to bring back different amounts of data and verify it completes in the appropriate amount of time based on environment ran on and volume of data.
Additional Information: See Oracle Payables User's Guide Release 12.2.
See E-Business Tax in this appendix.
Query an invoice that was not validated prior to the upgrade, then submit accounting for that invoice. Query an invoice that was accounted before the upgrade, cancel it, pay it, and then account for the payment. See Global Accounting Engine in this appendix.
Recommended Subledger testing for Payables includes, but is not limited to the following:
Test Subledger Business Scenarios for Payables
Create Online accounting for an upgraded invoice
Create Online accounting for an upgraded payment
Run the Create Accounting process to create accounting for an upgraded invoice
Run the Create Accounting process to create accounting for an upgraded payment
Run the Create Accounting process to create accounting for an invoice cancelled after the upgrade
Run the Create Accounting process to create accounting for a payment voided after the upgrade
Run the Create Accounting process to create accounting for an upgraded prepayment applied to a new invoice
Run the Create Accounting process to create accounting for an upgraded prepayment applied that was un-applied after the upgrade
Run the Create Accounting process to create accounting for a new invoice
Run the Create Accounting process to create accounting for a new payment
Create and account NEW Intra/Inter company invoices (if applicable)
View accounting for an upgraded invoice
View accounting for an upgraded payment
View accounting for a NEW invoice
View accounting for a NEW payment
Drill down from GL to upgraded Payables invoices/payments
Drill down from GL to NEW Payables invoices/payments
Run the Transfer Journal Entries to GL process to transfer any un-transferred accounting created after the upgrade
Test closing the period after the upgrade
These tasks apply only to Oracle Payments. In general, your planning for upgrade verification should involve testing in the two payment process areas:
Funds Disbursement - If you used Oracle Payables for issuing payments in Release 11i, you should plan to test the funds disbursement processes equivalent to the former payment batch flow to ensure that your upgraded data correctly reflects your business process.
Funds Capture - If you used Oracle Receivables for electronic payment processing such as direct debits or bills receivable remittances, you should plan on testing these areas to ensure that your upgraded data correctly reflects your business process. If you used Oracle iPayment for capture of funds from credit cards or bank account debits, you should plan on testing these processes to ensure that the upgraded data results in the process you expect.
Oracle Payments provides this new page where system-level settings for encryption, masking, and credit card security can be controlled. When your upgrade is complete, you should plan on reviewing the seeded settings in this page to ensure they meet your business needs. For example, in Release 11i masking of credit card values is controlled in different ways throughout the applications. In this release, the central setting in this page controls all masking. You will want to review the setting in this page and modify it if needed.
You may want to run reports for use in your upgrade verification testing. For example, you may want to use the Suppliers Report in Oracle Payables to verify the data upgrade for payment details and bank accounts on the payees created in Oracle Payments. You can use any reports that you ran before the upgrade to help verify upgraded data. In addition, there are some key setup entities that should be reviewed and used in testing payment processing.
Payment Process Profiles - You should plan on reviewing the settings for the seeded profiles created by the upgrade. These settings come from a variety of sources, and since the profile drives the entire funds disbursement flow it is important to verify that the setup supports your business process. You should pay special attention to the usage rules set on the seeded profiles as these can be changed if the upgraded values do not align with your needs. It is recommended that you run a test payment process with each profile that you plan to use in production.
Payment Methods - A new setup page is provided where payment methods can be created or updated. You should plan on reviewing the payment methods seeded by Oracle Payments to ensure that they meet your business needs.
Payment Systems and Accounts - You should plan to verify these entities after the upgrade, and in particular the required settings, values, and their links to the payment process profiles. This setup controls important parts of the funds disbursement process such as payment file transmission, so you should test this area to be sure that the process is working as you expect.
This setup page allows you to review and set system options used in the funds disbursement payment process. You should plan on reviewing the upgraded and seeded settings in this page to ensure they meet your business needs. For example, the option to allow override of the payee's bank account on a proposed payment is upgraded from the equivalent setting in AP Payables Options. You will want to verify that the upgrade correctly set this option for each of your operating units.
You may want to run reports for use in your upgrade verification testing. For example, you may want to run the Oracle Receivables Customer Detail Listing report to help verify the data upgrade for payment details and bank accounts on the payers created in Oracle Payments. You can use any reports that you ran before the upgrade to help verify upgraded data. In addition, there are some key setup entities that should be reviewed and used in testing payment processing.
Funds Capture Process Profiles: You should plan on reviewing the settings for the seeded profiles created by the upgrade. These settings come from a variety of sources, and since the profile drives the entire payment flow it is important to verify that the setup supports your business process. It is recommended that you run a test payment process with each profile that you plan to use in production.
Payment Methods: A new setup page is provided where payment methods can be created or updated. You should plan on reviewing the payment methods seeded by Oracle Payments to ensure that they meet your business needs.
Payment Systems and Accounts: You should plan to verify these entities after the upgrade, and in particular the required settings, values, and their links to the funds capture process profiles. This setup controls important parts of the funds capture process such as payment file transmission, so you should test this area to be sure that the process is working as you expect.
Payee and Routing Rules: You should review the system payee entity created by the upgrade and in particular verify that the routing rules are correct and will result in what you expect for your payment processing.
It is important that you plan to review the overall setup for the funds capture process flow. In particular, you should plan time to verify that the settings upgraded to the new process profiles, transmission configurations, and payment system accounts are correct. The upgrade program automatically migrates settings found in iPayment. However, due to the complex nature of areas like network configurations and required values for communication with your payment processors, the upgrade may not create all the new data as you expect.
You should also plan on reviewing the Payee configurations after you upgrade. You should review all the settings, but specifically check that the operating unit assignments are set the way you expect. These are set based on transactions in Oracle Receivables and the upgraded settings should be checked to ensure that you will process new funds capture transactions in the way you expect.
Once you have reviewed and made any corrections to the upgraded configurations, you should run a test payment process with each configuration that you plan to use in production.
With the introduction of Oracle Payments, the data model used for payment processing this release is considerably different than that in Release 11i. Please note in particular that the formatting of payment files has changed completely with the new framework and Oracle XML Publisher integration. It is important that you review any custom payment formats, extensions or other customizations that you have created in this business area, and plan for obsoleting them by using new functionality or rebuilding them to work on the new model. You should plan on testing any custom payment formats, extensions, or other customizations that you have created, and verify that they work with the new payments architecture.
These tasks apply only to Oracle Receivables.
Manually create an invoice and select a Tax Classification (Tax Code in Release 11i). Complete the invoice and verify that tax is calculated as it was in Release 11i.
Run a test tax calculation for each unique tax situation you plan to use in production.
Verify your tax setup in E-Business Tax and in the new Receivables Customer user interface.
See the E-Business Tax section of this appendix.
Query posted transactions (for example, Invoice, Debit Memo, Credit Memo, Chargeback, Deposit, Guarantee, Receipts, Adjustments) which have accounting dates in the current fiscal year. Use the Tools menu item and select 'View Accounting'. The journal lines should be represented correctly.
Query a transaction in the non upgraded fiscal year. Use the Tools menu item and select 'View Accounting'. You should get the message that you need to run the Subledger Accounting post-upgrade program.
Run the accounting reports in Receivables before and after the upgrade; verify your data.
Run AutoReceipts for invoices flagged for credit card payments and verify that the receipt is created successfully and that the receipt is authorized.
Run AutoRemittance for receipts flagged for electronic bank-to-bank payment and verify that the file is formatted properly in Oracle Payments.
Verify your tax setup in E-Business Tax and in the new Receivables Customer user interface.
See the Payments section of this appendix.
Verify that Consolidated Billing setups upgraded to site level Balance Forward Billing setups.
Run Balance Forward Billing program in draft mode and verify data on generated Balance Forward Bill.
Confirm Balance Forward Billing (recommended)
In this step you must submit the Confirm Balance Forward Bill program to accept or reject draft bills. From the appropriate Receivables responsibilities, navigate to Control > Request > Run and select 'Confirm Balance Forward Bill' from the list.
For additional information, refer to the Oracle Receivables User's Guide Release 12.2.
Print Balance Forward Billing (recommended)
This step is used to reprint draft or final balance forward bills. You must manually run the (BPA) Balance Forward Print program to reprint the bills.
For additional information, refer to the Oracle Receivables User's Guide Release 12.2.
Verify that Finance Charge and Global Interest Invoice Flexfield setups have been migrated properly in the new Customer user interface.
Run the Late Charges generation program and verify that late charges are generated as expected.
Query upgraded customer records and verify that setup attributes at the account, account site, and business purpose levels are the same as in Release 11i.
The following tasks apply only to Oracle Sourcing.
After the upgrade, log in as a sourcing buyer. Create a draft negotiation and verify that there is a Requirements section on the Create Negotiation: Header page. Also, confirm that the Header Attribute section is not available. Verify that Section Name has replaced Group Name.
After the upgrade, log in as a sourcing buyer. Retrieve an existing auction or Request for Quote (RFQ) template and verify that at the header level, there is a new field for Operating Unit. Verify that there is also a check box for Global Template.
Verify that the Subledger Accounting (SLA) upgrade completed successfully.
During the R12 upgrade, all periods to be upgraded are first marked as gl_period_statuses.migration_status_code=P, respective records are updated from the subledger (i.e., AP, AR, FA etc.) accounting tables to SLA's accounting tables, and finally the periods are marked as upgraded gl_period_statuses.migration_status_code=U. If some periods remain as not upgraded (i.e., gl_period_statuses.migration_status_code=P), then you may experience problems later while running the SLA upgrade or post upgrade patch. Run the following script to verify that the SLA upgrade completed successfully:
select * from gl_period_statuses where migration_status_code='P';
This SQL should NOT return any rows. If it does, then you must contact the appropriate Oracle Support team to log a bug on your behalf. See the Application_ID list in R12 SLA Upgrade: Check that the SLA Pre-Upgrade Completed Successfully (Doc ID: 747216.1) to determine which product is affected and to review further details on this issue.
The following tasks apply only to Oracle Trading Community Architecture.
To ensure the address validation setting has been correctly upgraded please check the following:
Ensure that the E-Business Tax migration of current setup data is completed.
Verify that Flexible Address Formatting (FAF) setup is correct after upgrade.
Customer setup should ensure that their Geography usage covers all data entry requirements for other usages, as this will be the point at which the user can correct the data. For example, if tax usage requires City, then this should be included in the Geography usage such that entry of City is required at data entry time. To avoid errors during address validation, the mapping for the Geography usage should match the FAF style for that country. In other words, the address should be validated based on the same data that is entered in the user interface.
Run the E-Business Tax Missing Location Values report to identify locations with null parents and update them if necessary. See the E-Business Tax section of this guide for more information.
The following tasks apply only to Oracle Treasury.
In this release, internal bank accounts are migrated from Treasury to Cash Management. Prior to the upgrade, take a snapshot of ALL (company, subsidiary, and counterparty) bank accounts and all their attributes. Also, take note of all counterparties used as banks.
After the upgrade, perform the following steps to verify that the bank accounts are properly migrated:
In the new bank account user interface, search for company bank accounts. Make sure all company bank accounts are displayed and all the bank account attributes are present.
In the new bank account user interface, search for subsidiary and counterparty bank accounts. Make sure all subsidiary and counterparty bank accounts are not displayed.
In the new bank and bank branch user interface, search for counterparties used as banks prior to upgrade. Make sure all counterparties that were used as banks for company and subsidiary bank accounts are now shown as banks and bank branches (one counterparty = one bank and one bank branch). Also make sure that in the Counterparty Profiles window such counterparties are marked as bank branches and linked to a bank branch.
In the new bank and bank branch user interface, search for counterparties used as banks prior to upgrade. Make sure that counterparties that were only used as banks for counterparty (external) accounts are not shown as banks or bank branches.
Additional Information: See the Oracle Cash Management User Guide for details.
In this release, bank account balances are migrated from Treasury to Cash Management. Prior to upgrade, identify a sample set of company, subsidiary, and notional cash pool bank accounts and take a snapshot of the bank account balance details of these accounts. Also, take a snapshot of all interest rates that are set up as default rates for bank account balances. These rates are not going to be upgraded and you will need to recreate them after upgrade as interest rate schedules.
After the upgrade, perform the following steps to verify that the company and subsidiary bank accounts are properly migrated:
In the new bank account balance user interface, search for the company and subsidiary bank accounts from the sample set. Make sure all pre-upgrade bank account balances are displayed correctly.
Create interest rate schedules in line with the pre-upgrade interest rate data and assign the bank accounts to these schedules, if not already assigned.
In the Bank Account Interest Settlement window, verify that the balances and interest amounts are correct.
After the upgrade, perform the following steps to verify that the notional cash pool balances are properly migrated:
In the new bank account balance user interface, search for the notional cash pools from the sample set. Make sure all pre-upgrade balances are displayed correctly.
In the Bank Account Interest Settlement window, verify that the balances and interest amounts are correct.
Additional Information: See the Oracle Cash Management User's Guide for details.
The following tasks apply only to Oracle U.S. Federal Financials.
Submit a payment process request from Oracle Payables with limited selection criteria in order to pay a few invoices. Have Treasury confirm the payment instruction in the the Treasury Confirmation and Reconciliation window and verify the subledger accounting was created as expected. This verifies not only the integration with Payments and the upgrade of existing Payables invoices, but also the treasury confirmation process and accounting in U.S. Federal Financials.
Enter budget execution transactions at various budget levels to verify the accounting is created as expected.
The following tasks apply only to Oracle Property Manager.
Perform these steps to verify that E-Business Tax, Subledger Accounting, and Legal Entity data was successfully upgraded:
Navigate to Property Manager > Leases and Documents.
Query for a lease that has been upgraded from 11i (one that had a term with Tax Code and Tax Group).
Navigate to Payment > Open and verify that Tax Classification Code is populated in the Payment Term.
Navigate to Term Templates and verify that Tax Classification Code is populated in the template.
Navigate to Property Manager > Leases and Documents > Subledger Accounting > Accounting Events.
Specify the start and end date along with ledger for which the SLA upgrade was done. The system displays a list of Finally Accounted accounting events.
Navigate to View Journal Entries and verify the entries.
Drill down for more information.
Submit the Receivables Auto Invoice Import program for importing the invoices with the Batch Name of Property Manager Batch Source.
Navigate to Export to Receivables/Payables > Transactions > Transaction Workbench.
If Legal Entity is associated correctly with the transaction, it signifies that the Legal Entity Upgrade for the Exported Line has been complete correctly.
The following tasks apply only to Oracle Projects.
In your Release 11i environment, run the AUD: Revenue Audit report for an accounting period in the current fiscal year that has been closed. After the upgrade, run the same report in your upgraded environment and compare the results.
Use the Event Types, Expenditure Types, and Invoice Review screens to check for invoices, event types, and expenditure types to make sure that they were upgraded successfully.
All upgraded Planning resource lists have the Enable Resource Class option set to 'Yes'.
All upgraded Resource Break Down structures have the Enable Resource Class option set to 'Yes'.
You can view existing resource lists that were successfully migrated to resource planning lists on the Planning Resource Lists page. You can also verify that the planning resources are the same as the resource list members.
Also the Resource Breakdown Structures page displays a resource breakdown structure with the same name as the resource list. Verify that the nodes of the resource breakdown structure are the same as the resource list members, and have the same two-level hierarchy if the resource list was grouped.
The existing labor costing rules should contain the following additional attributes with default values:
Costing Method: Standard
Enable Accrual: No
Enable Planning: Yes
Rate Source: Projects
Total Time Costing: No
This section contains upgrade verification tasks for the Oracle Supply Chain Management product family.
These tasks apply only to Oracle Cost Management.
To verify that the integration with Subledger Accounting was successful and that the data contains no discrepancies, complete these steps:
Verify that the accounting events for transactions prior to upgrade are available in the Subledger Accounting (SLA) events page. Verify and match the corresponding Journal Entries (headers and lines) for these accounting events.
Use the following reports to show balances and values derived from the accounting entries prior to the upgrade:
| Report Name | Use |
|---|---|
| Material Account Distributions (Details and Summary) | View the accounts charged for inventory transactions |
| WIP Account Distributions (Details and Summary) | View account information for work-in-process transactions |
| Discrete Job Value (Average and Standard) | Analyze a summary of the transactions behind the charges and variances for each job |
| Receiving Account Distributions | View accounting distributions for receiving transactions |
Use the Journal Entries Report - Cost Management to summarize the upgraded accounting entries in SLA by organization and accounting class. Compare the summarized account balance at the organization level between the reports listed in the reports in Step 2, and the SLA Journal Entry report.
The following tasks apply only to Oracle Order Management.
The upgrade process automatically produces a report (ontexc16.lst) that lists recommendations about, or errors that occurred during, the upgrade of Pre-Payment Order, Profiles moved to System Parameters, and Order Management Defaulting Rules. The report is located at $APPL_TOP/admin/<SID>SID>/out (UNIX) or %APPL_TOP%\admin\<SID>SID>\out (Windows), where <SID> is the value of the ORACLE_SID or TWO_TASK.
After the upgrade is complete, and before you use Oracle Order Management, you should review the report and fix any issues you find there.
The following tasks apply to Oracle Product Hub.
The Item or Item Revision business entity should be enabled for existing user defined attribute groups.
Seeded operational attribute groups should be enabled only at the Item Organization business entity.
Existing seeded pages for operational attributes should be available at Item Organization Level.
Existing New Item Requests will be converted and a line will be created with the details of item. The NIR line status will be same as NIR status.
Use diagnostic tools to install Oracle Diagnostics Support Pack.
Oracle E-Business Suite Diagnostics are launched exclusively from within the Oracle E-Business Suite using the Application Diagnostics responsibility.
For instructions on assigning the Application Diagnostics responsibility to your users, see the Responsibility Configuration section of eBusiness Suite Diagnostics Execution Instructions.
The 12.2 E-Business Suite includes the updated Diagnostic Support Pack. Follow the following Execution Instructions to confirm that the R12 Support Diagnostics are working properly:
Access the Application Diagnostics responsibility and select 'Diagnose'.
Within Oracle Diagnostics, choose the 'Select Application' button and query the desired application.
Select the desired Diagnostic Test and choose 'Execute'.
Enter test inputs and select 'Submit'.
Diagnostic patches may be available to get new diagnostic tests, bug fixes, and enhancements for existing diagnostic tests that were not released as part of your R12 base install. Reference the corresponding diagnostic catalog to find all available patches. If patches are available and required to get the current version of a diagnostic, then it will be noted in the Additional Comment section of the catalog for the specific test. You will also find the patch information in the Description and Important sections of the individual diagnostic test notes.
For additional information, see E-Business Suite Diagnostics References for R12.