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:
This section contains information about upgrade by request tasks for Oracle Customer Relationship products.
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:
Go to the $ASN_TOP/patch/115/sql directory.
Run asnmmres.sql, using old and new responsibility keys and application code as input.
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. |
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.
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:
Go to the $ASN_TOP/patch/115/sql directory.
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.
asnmrsc1.sql - generates the Multiple Salesreps Per Opportunity Line Report, which lists opportunities that have opportunity lines with more than one salesrep or partner getting revenue (or quota) sales credits.
asnmrsc4.sql - generates Non-Owner Single Partner Opportunity Report, which lists opportunities that have single partner who is getting revenue sales credits, but is not the opportunity owner. This report includes only information about partners, not sales representatives.
asnmrsc5.sql - generates Non-100% Non-Revenue Credit Receivers Report, which lists the non-revenue receivers whose credit percentage is not 100%. All non-revenue credit receivers are updated to 100% during the migration.
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:
Sum of quota credit percentage per line <> 100
Sum of quota credit amounts not equal to the line amount
You must correct the bad data before you continue with the next step. Re-run and make corrections until no bad data is reported.
Log in with the Oracle Sales Administrator responsibility.
Navigate to Concurrent Requests > Run.
Run the ASN Migrate Opportunity Multiple Salesrep and Owner concurrent request set. It contains the following concurrent programs:
ASN Migrate Duplicate Salesrep Opportunity Main Program
ASN Migrate Duplicate Salesrep Customer Main Program
ASN Migrate Duplicate Salesrep Lead Main Program
ASN Migrate Multiple Salesrep Opportunity Main Program
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. |
Repeat Step 2 to verify the migration results.
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.
The key features and actions of this concurrent program include:
| For this type of credit... | the program takes this action... |
|---|---|
| Revenue Sales Credits |
|
| Non-revenue Sales Credits |
|
Deletes duplicate salesrep records from the AS_ACCESSES_ALL table for each individual customer (organization or person) in the HZ_PARTIES table.
Deletes duplicate salesrep records from the AS_ACCESSES_ALL table for each individual lead in the AS_SALES_LEADS table.
Deletes duplicate salesrep records from the AS_ACCESSES_ALL table for each individual opportunity in the AS_LEADS_ALL table.
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:
Go to the $ASN_TOP/patch/115/sql directory.
Run asnmromt.sql.
If no Sales Stage is reported, go directly to Step 5.
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.
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.
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.
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.
Refer to the Subledger Accounting section of this appendix to learn about the Upgrade Historical Subledger Transactions program, which updates accounting and tax data.
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.
This step applies if you have reconciled journals in General Ledger:
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.
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.
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.
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.
This section applies if you have any of the following products:
Oracle Assets (for Subledger Accounting)
Oracle Financials for the Americas (for Subledger Accounting)
Oracle Payables (for both E-Business Tax and Subledger Accounting)
Oracle Projects (for Subledger Accounting)
Oracle Purchasing (for E-Business Tax)
Oracle Receivables (for both E-Business Tax and Subledger Accounting)
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.
The SLA post-upgrade process runs at the same time as the daily operations. You should carefully consider the impact of upgrading a large volume of data on your system performance.
A downtime upgrade can process a large volume of data more efficiently. However, the length of the downtime period increases with the volume of data.
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:
Run AutoPatch with options=hotpatch.
Specify $XLA_TOP/patch/115/driver/xla5584908.drv when prompted for the unified driver.
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.
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.
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.
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.