Skip Headers

Oracle E-Business Suite Upgrade Guide
Release 11i to 12.1.1
Part Number E16342-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Upgrade by Request

This appendix describes Upgrade by Request options - ways to upgrade historical data omitted from the initial upgrade process (critical downtime window). For example, instead of upgrading all your financial accounting data during downtime, you might include only the last fiscal year. If you want to upgrade other fiscal years - months or even years after - you can do so, at any time after the upgrade.

This appendix covers the following topics:

Customer Relationship Management

This section contains information about upgrade by request tasks for Oracle Customer Relationship products.

Sales

Read this section to:

Migrate Sales Online Custom Responsibilities

At any time after the upgrade, you migrate custom responsibilities from Oracle Sales Online to Oracle Sales. You can accomplish this migration manually when appropriate for your business requirements. However, we have created a script that you can use to migrate a custom Sales Online responsibility to an equivalent Sales responsibility.

The script (asnmmres.sql) takes old and new responsibility keys and responsibility application code as inputs. It does not create new responsibilities, but exits with an error if either the old or new responsibilities are not present. For each user having an old Sales Online responsibility, it assigns a new Sales responsibility, if it is not already assigned to that user, and end-dates the old responsibility.

To run the script, do the following:

  1. Go to the $ASN_TOP/patch/115/sql directory.

  2. Run asnmmres.sql, using old and new responsibility keys and application code as input.

  3. Repeat these steps for each Sales Online custom responsibility.

You can run the script multiple times for the same Sales Online responsibility to migrate it to multiple Sales custom responsibilities. You can also run it to migrate a Sales Online SuperUser responsibility to a custom responsibility without removing the end-date, even if it has been previously migrated.

Tips for creating custom responsibilities include:

Custom Responsibility Manual Instructions
Sales Online User Create a similar responsibility in Oracle Sales and provide both the old and new responsibilities to the script. You may need to specify a new menu for the Sales responsibility, similar to ASN_MAIN_MENU used by the Oracle Sales seeded responsibility for the Sales User.
Sales Online Manager The new custom responsibility for migration should be created for the Sales Intelligence application. It should be similar to the Sales Intelligence Sales Manager responsibility and may refer to the Sales DBI menu.
Sales Online SuperUser Create a new responsibility in Sales that is similar to the Sales Administrator responsibility. It may point to the ASN_ADMIN_MAIN_MENU structure.

Sales and Telesales

Read this section to perform the following tasks:

Note: Your application specialist must complete the instructions in this section before users can log on to Sales and Telesales after the upgrade.

Migrate Sales Credits

With Oracle Sales and Oracle Telesales, you can have only one sales person per opportunity line who receives the entire revenue credits for a line. The Release 11i Sales feature that allowed multiple sales people to receive credits on a single opportunity line is obsolete. Opportunities with multiple sales people, each receiving revenue credits for the same opportunity line, are migrated so that only one sales person is designated to receive credits for each opportunity line.

To migrate sales credits and sales teams, you run a series of report scripts and concurrent programs, as follows:

  1. Go to the $ASN_TOP/patch/115/sql directory.

  2. Run the SQL Report scripts. The system prompts you to enter a value for csv_report_file. Type the report file name and click Enter to generate the report.

  3. Generate Bad Data Sales Credits Report.

    Run asnmrsc6.sql to generate the Bad Data Sales Credits Report. It lists the revenue sales credit records that were not migrated. Opportunities with the following characteristics are included as bad data:

    You must correct the bad data before you continue with the next step. Re-run and make corrections until no bad data is reported.

  4. Log in with the Oracle Sales Administrator responsibility.

  5. Navigate to Concurrent Requests > Run.

  6. Run the ASN Migrate Opportunity Multiple Salesrep and Owner concurrent request set. It contains the following concurrent programs:

  7. Click on the Parameters field for each program to see the list of required parameters.

    Parameter Name Value
    Number of Workers Number of concurrent manager processes that you have running
    Commit Flag Yes = commit changes. No = do not save changes.
    Debug Flag Yes = log messages in Application Common Logging Repository. No = do not log messages.
    Note: To log debug messages, you must set profile values for FND Logging Framework.
  8. Repeat Step 2 to verify the migration results.

Migration Example:

An opportunity (Business World – Sell New Product) has an opportunity line for Brand-new Product, with two sales people (John and Mary), each receiving revenue credits. The opportunity line is for $200, with John and Mary receiving revenue credits of 75% ($150) and 25% ($50), respectively.

The upgrade creates a new opportunity line for the product and assigns one of the sales people (let’s say Mary) to the line. The new line has a line amount of $50, revenue credit of 100%, and revenue credit amount of $50. It updates the existing opportunity line to be $150, with revenue credit of 100%, and revenue credit amount of $150. John is the only sales person who receives revenue credits on the existing opportunity line.

The total opportunity header amount remains the same, but the opportunity now has two opportunity lines for the same product. Each line has only one sales person who receives revenue credits.

Features of ASN Migrate Multiple Salesrep Opportunity Main Program:

The key features and actions of this concurrent program include:

For this type of credit... the program takes this action...
Revenue Sales Credits
  • Ensures that no opportunities have more than one salesrep who receives quota credits per opportunity line. For opportunities with lines that have multiple salesreps receiving quotas, the program creates a new line within the same opportunity for every salesrep in the original opportunity line (who receives quota credits). The program merges credit records for any salesrep who gets quota credits multiple times.

  • Deletes all quota sales credit lines with 0% quota allocation.

  • Transfers revenue sales credits to opportunity owner (who is also an employee and an internal salesrep), if a partner is getting revenue sales credits.

  • Assigns all salesreps receiving quota and non-revenue sales credits to a sales team.

  • Defaults Best, Worst, and Forecast values only if the opportunity line amount is updated or if it is newly created, and is based on the value of profile ASN: Forecast Defaulting Type.

  • Grants full access to the opportunity to all sales credit receivers.

Non-revenue Sales Credits
  • Assigns all partner non-quota credits to the owner of the opportunity.

  • Sets all non-quota credits to 100% regardless of the current number.

  • Checks uniqueness of non-revenue sales credit receivers. Deletes duplicate non-revenue credits (based on sales force, sales group, and credit type).

  • Defaults Best, Worst, and Forecast values only if the opportunity line amount is updated or if it is newly created, and is based on the value of profile ASN: Forecast Defaulting Type.

  • Grants full access to the opportunity to all sales credit receivers.

Features of Customer/Lead/Opportunity Duplicate Sales Team Migration:

Migrate Sales Methodologies for Opportunities

In Oracle Sales and Oracle Telesales, sales methodology is required if a sales stage is specified in an opportunity. Once specified, you cannot change to any other sales methodology for that opportunity. The sales methodology script asnmomth.sql) migrates only the opportunities that have the sales stage without a sales methodology. The script randomly selects an active sales methodology that is mapped to a given sales stage. It reports errors if there are no active methodologies mapped to the sales stage. Whether a sales methodology is active depends on the start and end date of the methodology.

To avoid errors and improper migration, prepare for the migration by running the asnmromt.sql script to ensure that there is only one active sales methodology per sales stage.

Note: The system prompts you to enter a value for csv_report_file. Type the report file name and click Enter to generate the report.

Review the generated report, and correct the setup before you migrate the data.To run the script, do the following:

  1. Go to the $ASN_TOP/patch/115/sql directory.

  2. Run asnmromt.sql.

  3. If no Sales Stage is reported, go directly to Step 5.

  4. If a Sales Stage is reported, then correct the Sales Methodology and Sales Stage setup based on the information in the report. Run the report and make corrections until no Sales Stage is reported.

  5. Run asnmomth.sql to migrate the Sales Methodologies in Opportunities.

The script reports sales stages that must be migrated in opportunities and have zero or more than one active sales methodology mapped to. Changing a sales methodology or a sales stage can impact other methodologies or stages. It’s good practice to generate the latest report after you make any modifications.

Financials and Procurement Tasks

This section contains information about upgrade by request tasks for the Oracle Financials and Procurement product family. Except where noted, it describes how to upgrade the historical transactions and journal entries for E-Business Tax and/or Subledger Accounting for each of the products listed. A description of the overall process of upgrading historical subledger journal entries is provided in the Subledger Accounting section of this appendix.

Assets

Read this section to:

Upgrade Historical Assets Transactions for Subledger Accounting

If you require additional accounting entries to be migrated into Subledger Accounting from Assets, you can run the SLA post-upgrade process. It calls a package that upgrades all Assets transactions for the specified ledger and period.

E-Business Tax

Refer to the Subledger Accounting section of this appendix to learn about the Upgrade Historical Subledger Transactions program, which updates accounting and tax data.

Financials for the Americas

Read this section to:

Upgrade Historical Brazilian Receivables Transactions for Subledger Accounting

By default, only the current fiscal year’s Brazilian Receivables collection document occurrences that are already posted to General Ledger and all un-posted occurrences are migrated as part of the upgrade. You can optionally change this period from current fiscal year to a longer period for a ledger. In addition to the occurrences falling into the upgrade period, all remittance occurrences of the collection documents that have one or more occurrences that fall into the upgrade period are also upgraded, so that the backward references to the Subledger journal entries of these remittance occurrences are addressed.

If you require additional journal entries for previous fiscal years occurrences to be migrated into Subledger Accounting, then you can run the SLA post-upgrade process. It calls a package in Receivables that upgrades the Brazilian Receivables Transactions for the specified ledger and period, in addition to the other Receivables transactions.

General Ledger

This step applies if you have reconciled journals in General Ledger:

Journal Reconciliation

TUMS Step Key: GL_CREATE_RECON_LINES

This new feature replaces the General Ledger Entry Reconciliation functionally from within Oracle Financials Common Country Features. It enables you to reconcile journal lines that should net to zero. It is often used to reconcile suspense accounts, or in countries like Norway, Germany, or France, to audit or reconcile payroll and tax-payable accounts or to verify open balances of specific accounts at the end of a period.

If you want to reconcile journal lines entered prior to the upgrade or to view and reverse reconciliations performed prior to the upgrade, then run the Upgrade Journal Lines for Reconciliation concurrent program.

Payables

Read this section to:

Upgrade Historical Payables Transactions for Subledger Accounting and E-Business Tax

The Subledger Accounting upgrade processes accounting and tax data. During the upgrade, you specify periods for which you want to perform the upgrade. If at any point after the upgrade, you find a need to adjust a payment or prepayment that did not fall in this upgrade period, you can run the SLA post-upgrade process. It calls a package in Payables that upgrades all transactions in Payables for the specified ledger and period.

Purchasing

Read this section to:

Upgrade Historical Purchasing Transactions for Subledger Accounting and E-Business Tax

The Subledger Accounting upgrade processes accounting and tax data. If you need to migrate additional tax data to the E-Business Tax repository from Purchasing, you can run the SLA post-upgrade process. It calls a package in E-Business Tax that upgrades all appropriate tax transactions in Purchasing for the specified ledger and period.

Receivables

Read this section to:

Upgrade Historical Receivables Transactions for Subledger Accounting and E-Business Tax

The Subledger Accounting upgrade processes accounting and tax data. If you need to migrate additional accounting entries to Subledger Accounting from Receivables, run the SLA post-upgrade process. It calls a package in Receivables that upgrades all Receivables transactions for the specified ledger and period.

Subledger Accounting

This section applies if you have any of the following products:

SLA Post-Upgrade Process

To avoid a long downtime period, you could choose to upgrade only a subset of the accounting and tax data, for example, if old data does not need to be permanently available for daily operations. This decision has a direct impact on hardware resources since less data requires less storage space. However, during normal business operations, some situations may require old data to be available. For example, if you need to reverse an old invoice, Oracle Subledger Accounting requires the original accounting data for the invoice to generate the correct accounting reversal.

Note: The SLA post-upgrade process should not be considered a replacement for a downtime upgrade. Its goal is to upgrade only individual periods of a given ledger - during downtime, multiple ledgers are upgraded at the same time.

It is important to consider the impact on resources when determining the upgrade strategy.

Before running the SLA post-upgrade process, enter the initial date to be used to determine the initial period to be upgraded in the SLA: Initial Date for Historical Upgrade profile option. This profile option must be populated in order to run the process.

Then, 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.

Projects

This section contains information about upgrade by request tasks for Oracle Projects, which is related to Subledger Accounting. A description of the overall process of upgrading historical subledger journal entries is provided in the Subledger Accounting section of this appendix.

Projects

Read this section to:

Upgrade Historical Projects Transactions for Subledger Accounting

If you need to migrate additional accounting entries to Subledger Accounting from Projects, you can run the SLA post-upgrade process. It calls a package in Projects that upgrades all appropriate accounting entries for the specified ledger and period.

Supply Chain Management

This section contains information about upgrade by request tasks for Oracle Cost Management in the Oracle Supply Chain Management product family. A description of the overall process of upgrading historical subledger journal entries is provided in the Subledger Accounting section of this appendix.

Cost Management

Read this section to:

Upgrade Historical Cost Management Transactions for Subledger Accounting

If you require additional accounting entries to be migrated into Subledger Accounting from Costing, then you can run the SLA post-upgrade process. It calls a package in Costing that upgrades historical Inventory, Work in Process, and Receiving Transactions for the specified ledger and period.