This appendix describes the way the upgrade affects your existing Customer Relationship Management (CRM) products, and highlights the impact of these functional changes on your day-to-day business. It is arranged by alphabetically by products in the Customer Relationship Management product family.
This appendix covers the following topics:
An Applications upgrade alters both the technical and functional aspects of your Oracle E-Business Suite system. In addition to changes to the technology stack and file system, an upgrade also initiates specific changes that affect the way your existing products work after the upgrade and the way they look and feel. These functional changes have an impact on the way you use the products as you conduct your daily business.
Note: This appendix describes some of the ways the upgrade changes your existing products. We assume that you have read about the new features and products delivered in this release, which is included in the product-specific Release Content Documents (RCDs) and TOI on My Oracle Support.
The discussions of the functional aspects of the upgrade in this chapter are arranged by products within the Customer Relationship Management product family.
Your Customer Relationship Management applications specialists should be completely familiar with the information in this section and should have made appropriate plans to accommodate the associated changes before you begin your upgrade.
This section outlines changes made to Oracle Advanced Inbound.
The customer lookup feature has changed as follows:
In Release 11i, Customer Lookup was defined at the server group level and accessible in the Call Center HTML Setup UI (Classification > Customer Lookup). In this release, navigate to the Classification Rule configuration page to configure Customer Lookup.
After the upgrade, all classifications have a default value of No Customer Lookup. You must set up customer lookup to use the available classification rules.
The Basic Telephony feature has changed as follows:
Profile options CCT:BasicTelephony: ACD ID, CCT: Basic Telephony: ACD Password, and CCT:Basic Telephony: ACD Queue have been removed. The data from these profile options has been migrated to CRM Resource Manager.
To view existing ACD agent configuration, navigate to CRM Resource Manager and select the desired agent. ACD agent parameters are configured for the seeded middleware (BASIC_MIDDLEWARE).
No other changes have been made to profile options used by Basic Telephony.
In this release, Oracle Advanced Inbound does not support active mode routing for inbound calls. If you are currently using this feature, you must use either Enhanced Passive Mode or Passive Mode.
Note: See Oracle Advanced Inbound Implementation Guide for more information on setting up your call center to run either of these modes.
You may continue to use active mode routing for web callbacks.
In this release, the install process is changed as follows:
The ieoicsm.class file has moved from $APPL_TOP/html/download/ to $INST_TOP/appl/download/ieo/.
After an initial installation, or anytime a patch for CCT, IEO, or UWQ is applied, run the following command to regenerate ieoicsm.class:
$INST_TOP/admin/scripts/ieo/ieozipmain.sh
If you are not using the APPL_TOP installation for running your ICSM server, then download ieoicsm.class using a secure FTP from $INST_TOP/appl/download/ieo/ to the target directory on the target ICSM node.
Release 11.5.10 was the terminal release of Oracle Field Sales (Sales Online). In this release, Field Sales is obsolete. If you are using this product, you must upgrade to the Oracle Sales application. This change results in a functional impact for all users. We recommend that you complete a functional analysis before you migrate Field Sales (Sales Online) data to Oracle Sales.
Note: See Migrate Sales Credits in this appendix for more information.
This section outlines changes made to Incentive Compensation.
Out-of-the-box, Inventive Compensation delivers a set of responsibilities, each with the appropriate business flow permissions. Consequently, menus and responsibilities that existed or were created in Release 11i are end-dated. You must assign the new responsibilities to existing users after you complete the upgrade.
The new responsibilities are described in the following table:
| Responsibility | Description |
|---|---|
| Incentive Compensation Administrator | Responsible for configuring and maintaining OIC application setups, and administering and scheduling OIC concurrent programs. A configuration workbench provides a checklist of tasks as a guide for the process of implementing or administering OIC. |
| Plan Administrator | Responsible for building compensation plans and plan components, maintaining compensation plans, and maintaining product hierarchies and rule definitions that are used across compensation plans. Can access a single page that provides a comprehensive view of a plan. It contains a Design section (plan components and links), an Eligibility section (roles and resources), and a Notes section (history of plan changes). In addition, the plan creation flow supports top-down creation, making it possible to create a plan, and add and create components as needed. The plan elements creation checklist provides simple, discrete steps that can be checked off as the plan elements are completed and validated. The plan administrator also has access to a component library workbench. |
| Compensation Manager/Analyst | Responsible for managing resource compensation plans, reviewing and handling disputes, and administering the compensation process. Can access a single page that provides a comprehensive view of a resource. It contains a Roles/Group section (resource maintenance), a Plans section (customization maintenance or payment plan/paygroup assignments), a Compensation section (historical compensation reports), and a Notes section (history of resource changes). The Analyst can run a validation process to flag any incomplete compensation plan setups, and can use the transaction detail and status details page to aid in dispute resolution. |
| Incentive Compensation User (Manager Self Service) | Responsible for monitoring resource performance and distributing quotas and contracts to resources. Has access to compensation reports for any resources rolling up to him. The Year-to-Date Summary and Earnings Statement reports have been re-written using the new technology stack. |
| Incentive Compensation User (Self Service) | Views incentive statements and reconciles payments with expected compensation. Information in reports can be exported to a CSV file. Compensation information can be published as a PDF document. |
Multi-Org Access Control (MOAC) allows a single responsibility to access multiple operating units. An Incentive Compensation Administrator can configure system setups for multiple operating units without having to log in using a separate responsibility for each operating unit. OIC Compensation Managers can query and modify transactions and resources for multiple operating units without having to log in using a separate responsibility for each operating unit.
In Release 11i, you had to set up mapping for territory qualifiers in order to use the TAE in Sales Crediting and Allocation. In this release, OIC automatically provides the mapping and populates the table with data using one of two mapping options as a part of the post-collection process.
Option 1: Use the seeded OIC attribute/territory qualifier mapping provided in this release.
Option 2: Continue to use the existing OIC attribute/territory qualifier mapping
Note: See the Oracle Territory Manager Functional Upgrade document for details on using these two options.
To schedule collections using the new concurrent program:
Territory Manager allows you to run the concurrent program “Synchronize Territory Assignment Rules” (STAR), which replaces the existing GTP concurrent program. You can run it in total, incremental, and date-effective mode. Total and Incremental mode behave in the same manner as in 11i for all consumer applications. Date effective mode is only applicable to OIC.
The “Synchronize Territory Assignment Rules” (STAR) concurrent program accepts the following parameters:
Usage
Transaction Type
Run Mode
Start Date
End Date
Debug Flag
The pre-processing APIs (dynamic packages) created by the “Synchronized Territory Assignment Rules” concurrent program has been decommissioned.
Additional setup parameters support multi-level marketing requirements. For example, it is possible to track the level of rollup for each OIC transaction.
The plan element setup includes a rollup calculation option. When a plan element is configured, you can choose whether to calculate commissions for rolled-up transactions. You can choose to calculate for all resources or only for managers.
Some common system-level profile options are now defined as parameters that can be changed in the OIC Administrator Configuration Workbench. The OIC Administrator will need to use the Configuration Workbench to manually set these parameters.
| Release 11i Profile Option | Workbench Task | Release 12 Parameter Name |
|---|---|---|
| OSC: Default Custom Flag | Application Parameters | Customize Compensation Plans |
| OSC: Default Conversion Type | Application Parameters | Currency Conversion Type |
| OSC: Reporting Hierarchy | Application Parameters | Reporting Hierarchy for Manager Access to Resources Reports |
| Display Draw | Application Parameters | Display Draw in Year To Date Summary Report? |
| OSC: Apply Non-Revenue Split to Quantity | Collection | Collect Quantity for Non Revenue Credit Receivers |
| OSC: Negate during Revenue Adjustments Collection | Collection | Negate Original Transactions during Revenue Adjustments Collections |
| OSC: Reset Error Transactions | Collection | Re-load Errored Transactions |
| OSC: Collect on Acct Credits | Collection | Collect Credit Memos from Oracle Receivables |
| OSC: Customized Summarization | Calculation | Aggregate Transactions Based on Custom Criteria during Rollup |
| OSC: Prior Adjustment | Calculation | Allow Prior Period Adjustments |
| OSC: Roll Summarized Transactions | Calculation | Aggregate Transactions during Rollup |
| OSC: Commission Rate Precision | Calculation | Numeric Precision for Rate Tables |
| OSC: Income Planner Disclaimer | Collation | Display Projected Compensation Disclaimer? |
The following profile options from 11i have changed.
| Release 11i Profile Option | Release 12 Profile Option | Default |
|---|---|---|
| OSC: Validate Payment Worksheet Statuses | OIC: Enforce Payment Worksheet Approval | Y |
| OSC: Payroll Action If Entry Exists | OIC: Approve or Reject Duplicate Payment Transactions | Rejected |
| OSC: Sleep Time in Seconds | OIC: Frequency of Batch Runners Status Check | 30 seconds |
| Total Rev % is Not 100 | OIC: Allow split % less than 100% | Custom |
| OSC: Number of Batch Workers | OIC: Number of Batch Workers for Credit Allocation | 1 |
| OSC: Debug Mode | OIC: Enable Debug Mode | NO/N |
| OSC: Invoice Split Upgrade Start Date | OIC: Invoice Split Upgrade Start Date | Null |
| OSC: Invoice Split Upgrade End Date | OIC: Invoice Split Upgrade End Date | Null |
| OSC: LOV Input Validation | OIC: LOV Input Validation |
*If you want to change this option to Pay By Transaction = Y during the upgrade, you must make sure all Payruns/Worksheets are Paid. If you do not, the resources will no longer be usable as the data will become corrupted.
The following table lists changes in terminology:
| Release 11i Term | New Term |
|---|---|
| Accelerator | Multiplier |
| Direct Resource | Direct Credit Receiver |
| Employee Number | Salesperson Number |
| Functional Currency | Ledger Currency (Terminology change from GL) |
| Incentive Type | Calculation Type |
| Payment Factor | Earnings Factor |
| Pay Periods | Compensation Periods |
| Payrun | Payment Batch |
| Quota Factor | Multiplier |
| Rate Schedule | Rate Table |
| Revenue Class | Product or Eligible Product |
| Sales Credit | Credit Amount |
| Salesperson | Resource |
| Set of Books | Ledger (Terminology change from GL) |
| Worksheet | Paysheet |
The Quota Performance report is replaced by the Attainment Summary report, and the Sales Force Planning Module and Income Planner have been decommissioned. See My Oracle Support (Doc ID: 338866.1).
Note: The Income Planner projected compensation calculator does not incorporate many of the settings provided in OIC-implemented compensation plans. Consequently, the sales pipeline projections may be inaccurate.
One-to-One Fulfillment has improved the performance for mass email request fulfillment. The server now uses multiple threads on the Java process, and new server-level flags have been added.
When installed, the fulfillment server routes mass email requests through the new multi-threaded fulfillment process. You can turn this process off by update the JTO: Server: Use Multithreaded Fulfillment profile option.
The recording of Interaction History for the mass email requests has been moved out of the main processing thread, and now uses a batch routine. You should schedule the Interaction History Bulk Processor concurrent program so it runs on a regular basis.
The new JTO: Purge Fulfillment Requests concurrent program lets you purge data related to old fulfillment requests. It uses multiple database workers so that it can process a large number of rows. You can schedule it to run on a periodic basis by setting the relative age of the fulfillment request on the run date.
The fulfillment server allows Display Name, From and Reply To values that can be merged in the email header. You must define the default value for Display Name on the email server setup screen.
Bounce back functionality works with or without the sendmail configuration changes. You no longer have to update the sendmail configuration to direct bounced messages to a single bounce back account.
This section describes the changes made to Oracle Order Capture/Quoting.
The following actions are changed in Trading Community Architecture:
Selecting party, account and address together in the Search and Select: Customer flow is not supported by the TCA common components.
Account - the oldest account, if any, is defaulted after the party has been selected. If there are multiple accounts for the party, you must change the account after selecting the party.
Address - only the identifying address is displayed in search results instead of all addresses. This address is not selected when the party is selected. You must select the address after the party is selected. It is possible to select party, account, and contact together.
Contact - contact information is not displayed. You must select the contact after the party is selected. One alternative is to set up defaulting rules to default in an address and contact when the party is selected.
Contact and Address can no longer be displayed and selected together on the Search and Select: Address flow. However, address search results can be filtered to show addresses for the current quote_to/ship_to/bill_to contact.
TCA components do not support the standard text box LOVs. Therefore, you can no longer clear the quote to/ship to/bill to customer contact and ship to/bill to customer.
Saved searches created in earlier releases are not available after the upgrade. You must re-create them in your upgraded system.
You must re-implement selectable columns in earlier releases and changes to the sidebar menu in quote detail by using Oracle Applications personalization.
Oracle XML Publisher replaces Oracle Reports. You must re-create any customized Print Quote reports using Oracle XML Publisher.
Product search does not support non-Intermedia search.
The new selectable column Adjustment Amount has replaced Line Discount column used in Release 11i. The Line Discount column is no longer necessary since you can now discount by amount as well as percent.
You cannot drill down for the Account number. Oracle Sales (ASN) no longer has account information in the customer detail pages.
This section describes the changes made to Oracle Sales.
In this release, all Sales Online users are migrated and assigned an Oracle Sales responsibility as follows:
All users with Sales Online User responsibility are assigned the Sales User responsibility
All users with Sales Online Manager responsibility are assigned the Sales Manager (Sales DBI) responsibility
All users with the Sales Online Superuser responsibility are assigned the Sales Administrator responsibility
All profile options used by Sales Online (including MO: Operating Unit) are migrated to a corresponding profile option in Oracle Sales.
| This Sales Online profile option... | is replaced with this Sales profile option... |
|---|---|
| OS: Forecast Calendar | ASN: Forecast Calendar |
| OSO: Forecast Calendar Month | ASN: Forecast Calendar Month |
| OSO: Default Forecast Period Type | ASN: Default Forecast Period Type |
| OSO: Default Forecast Category | ASN: Default Forecast Category |
| OS: Forecast Sales Credit Type | ANS: Forecast Sales Credit Type |
| OS: Default Opportunity Win Probability | ASN: Default Opportunity Win Probability |
| OS: Default Sales Channel | ASN: Default Opportunity Sales Channel |
| OS: Default Opportunity Status | ASN: Default Opportunity Sta |
| OS: Default Close Date Days | ASN: Default Close Date Days |
| OSO: Forecast Pipeline Calculation | ASN: Forecast Defaulting Type Basis |
| OS: Default Win/Loss Status | ASN: Default Win/Loss Status |
| OS: Default Status For Leads | ASN: Default Lead Status |
| OS: Manager Update Access | ASN: Manager Update Access |
| OS: Opportunity Access Privilege | ASN: Opportunity Access Privilege |
| OS: Customer Access Privilege | ASN: Customer Access Privilege |
| OS: Sales Lead Access Privilege | ASN: Lead Access Privilege |
| MO: Operating Unit | MO: Operating Unit |
| OS: Sales Admin Update Access | ASN: Sales Admin Update Access |
| OSO: Default Country | HZ: Reference Territory |
| OS: Sales Team Creator Keep Flag | ASN: Default value for sales team Do Not Reassign flag |
All FND lookup types used by Sales Online are migrated to a corresponding lookup type in Oracle Sales.
| This Sales Online lookup type... | is replaced with this Sales lookup type... |
|---|---|
| LEAD_CONTACT_ROLE | ASN_CONTACT_ROLE |
| CONTACT_RANK_ON_OPPORTUNITY | ASN_CONTACT_ROLE |
| CLOSE_REASON | ASN_LEAD_CLOSE_REASON |
| CLOSE_REASON | ASN_OPPTY_CLOSE_REASON |
| VEHICLE_RESPONSE_CODE | ASN_VEHICLE_RESPONSE_CODE |
This section describes changes that are common to both Oracle Sales and Oracle Telesales.
In Oracle Sales, an opportunity can have multiple opportunity lines, and for each line, there can be a different sales person receiving revenue credits. However, there can be only one sales person who receives all revenue credits for an opportunity line.
This release upgrades opportunities that have multiple sales people receiving revenue credits for the same opportunity line and ensures that there is only one sales person receiving revenue credits for the line. Opportunities having multiple sales people on a single opportunity line are upgraded.
Similar to Oracle Sales, Oracle Telesales also supports only one sales person receiving revenue credits for each opportunity line.
Your Service applications specialists should be completely familiar with the information in this section and should have made appropriate plans to accommodate the associated changes before you begin your upgrade.
The following topics describe changes to Email Center and suggest where you can find additional information on specific feature-specific changes or what additional steps you may need to take to accommodate the changed functionality.
Email Center can connect to any IMAP4-compliant mail server, download messages into the Email Center schema, and process those messages. New setup and administration screens are associated with this change.
Email Account Administration: Administrators can directly define email account parameters using the new account administration screens available in the Email Center Administrator console. For example
Scenario 1: Email messages are redirected from the corporate mail server as part of Email Center implementation in the current release as follows:
Releases 11.5.9 and 11.5.10: Account myermsaccount@mycompany.com has a redirect-rule that routes the email messages to myermsaccount@oesmailserver.com, which was created from the Email Center Self-Service Administration console.
Release 12: Administrators can directly define the email account details using the account administration screens.
Note: In both the scenarios, if data migration is planned as part of the upgrade, email accounts like myermsaccount@oesmailserver.com will be migrated, along with email data, into the new configuration tables and marked Inactive. You can access this account from the new account administration screens, update the account properties as required, and activate them to work in the Release 12 flows.
Download Processor: The Email Center Download Processor is a mid-tier service that runs at intervals you configure to connect and download email into the Email Center schema. Using configuration data defined in Email Center for an email account, it can connect to the email account and download email messages for further processing.
When an email account is defined in Email Center, the system creates Oracle Processed and Oracle Retry folders in that account. Once a message is downloaded, both the metadata and the content of the email remain in the Email Center schema until an administrator purges it.
The new backend server architecture for Email Center introduces new configuration and transactional tables. Because all prior Email Center releases must have a migration path to the new architecture, this release ships a set of data migration tools. They consist of the following components:
Download Processor - migration mode: In this mode, the Download Processor can connect to email accounts residing in Oracle Email Server and retrieve email from all folders into the Release 12 schema.
Email Center Migration concurrent programs: These programs control the reconciliation of email migration data with the Oracle Customer Interaction History and are responsible for moving email into the right message store.
Migration Console: These screens in the Email Center Administration console allow administrators to monitor data migration and also to advise on the status of the migration.
As a part of the shift from a message stored based on Oracle Email Server to one based on a local message store, the out-of-the-box workflow included has bee modified to remove from the keys all references to data based on the Email Server. If an implementation has any customer workflow hooks that were used to implement specific flows not available out-of-the-box, you must change the code and retest it.
Email messages with actions before the upgrade are known as live messages. After the migration, Email Center agents can access live messages in a pre-migration state and take appropriate action. The messages are generally in a queue waiting to be acquired by the agents or are already acquired by an agent and waiting in the agent’s Inbox. The percentage of data in this state in a live Email Center implementation depends on the email volume at the site.
Do not use the Email Center until the live message migration is complete. The downtime is fairly small and depends on the number of emails in a live state.
Email messages processed in Email Center are retained in the Oracle Email Server message store and accessed for auditing and for tracking customer interactions. The percentage of data in this state could be fairly high in an implementation that has been in production for some time.
The Email Center Migration concurrent program provides the Cut-off Date for Historical Emails parameter, which defaults to 30 days. You can decide how much of the historical data is to be migrated. Historical data that is not migrated is no longer available for viewing from the Email Center application. However, large amounts of historical data may result in a lengthy migration process.
Note: The number of email messages that qualify for migration affects the duration of the migration process. To reduce the duration, decide on a cut-off date for historical email data. Once the live message migration is complete, you can use the Email Center while the historical data migration runs in the background. Reduced number search results could result, but they will be accurate after the process is complete.
Your iSupport applications specialists should be completely familiar with the information in this section and should have made appropriate plans to accommodate the associated changes before you begin your upgrade
If you have defined custom user types prior to this release, and you wish to continue to leverage those types during iSupport registration, you must manually associate the user type keys with the relevant iStore lookup types in the AOL lookups table after the upgrade. If you do not complete this task, iStore cannot determine the user types, and they will not be available on the registration pages by the registering user.
The lookup types are:
IBE_UM_INDIVIDUAL_USER_TYPES
IBE_UM_PARTIAL_USER_TYPES
IBE_UM_PARTNER_USER_TYPES
IBE_UM_PRIMARY_USER_TYPES
IBE_UM_SECONDARY_USER_TYPES
IBE_UM_STORE_USER_TYPES
For example, the seeded iSupport user type IBU_INDIVIDUAL is mapped to the iStore lookup type IBE_UM_INDIVIDUAL_USER_TYPES. You must use the Lookups form to perform the same action for all customized user types.
Oracle TeleService has improved the processing of services requests, added functionality and configurability options for Contact Center, and added new capabilities for Customer Support.
This section describes the enhancements to Oracle Service and Infrastructure in this release.
Improved Processing of eAM Service Requests
Prior to this release, all item instance-related fields, including the Subject tab, were disabled for eAM service requests. In this release, these fields and the Subject tab are enabled for eAM service requests and a new field (Maintenance Organization) has been added to identify the servicing organization. The field is mandatory for eAM service requests and can be defaulted either from a profile option or from the asset definition
XML Publisher Service Request Report
HTML service request reports from previous releases have been replaced with the new XML Publisher reports. You now have the option of specifying various parameters to generate a report, including which template to use, the language, and the output format.
Migration to Multi-Org Access Control (MOAC for Charges
Prior to this release, the Charges functionality allowed you to create charge lines for all valid operating units. When the charges were submitted to Order Management, the application validated that you had access to the operating units in which each individual charge line was created. This access was maintained in, and verified against, the Extra Information Type (E.I.T.) descriptive flexfields in Oracle Human Resources for each operating unit. These security grants were shared across all users and responsibilities, and thus did not support different security policies for different user groups.
In this release, a migration to the MOAC infrastructure moves this access control to the Security Profile functionality in Oracle Human Resources. Each security profile can be independently defined and associated to an application responsibility, enabling the support for different security policies for different groups of users. Customers currently using E.I.T. must migrate their security policies to the new Security Profile functionality.
Note: See Oracle TeleService Implementation Guide for more information.
In addition:
Service Request default Operating Unit profile option
In Release 11i, the MO: Operating Unit profile option used in Release 11i to default the operating unit for service requests is migrated to the new Service: Service Request Default Operating Unit profile option.
Service Default Operating Unit
In this release, the Operating Unit field (hidden out of the box) has been renamed Service Default Operating Unit. Its value is derived from the Service: Default Operating Unit profile option and stamped on the service request record.
Automatic Assignment Process
In Release 11i, you could specify excluded resources in Service Contracts and Install Base, but these resources, unlike the “preferred” resources, were not used during the automatic assignment process of service requests and service request tasks. In this release, the automatic assignment process validates the resources returned from the Territory Manager and filters out any resources that were defined as "excluded" in Service Contracts and Install Base.
Note: Any resources defined as excluded, and using automatic assignment process, are not picked up as potential owners of the service requests and service request tasks.
Assignment Manager UI
In Release 11i, the Assignment Manager UI (accessible from the Service Request form) exposed only matching attributes (previously called qualifiers) enabled in the Territory Manager for a given Operating Unit. In this release, you can use any of the enabled matching attributes, regardless of the Operating Unit in which they were enabled.
This change can potentially change the assignment if both of these conditions are met:
The Assignment Manager UI is used to perform the assignment process. This change has no impact on the business logic of automatic assignment process.
Different sets of matching attributes (qualifiers) have been enabled in different Operating Units.
As the Assignment Manager UI shows the matching attributes across all Operating Units, you can select matching attributes enabled for Operating Units other than the one associated with the Service Request. If the Service territory setup uses those matching attributes, the Assignment Manager UI may present a different set of candidate resources than it would if only matching attributes for a given Operating Unit were used.
Setup Menu
In Release 11i, all Service Request setups were under a single menu (Service Request). In this release, the various setups are categorized into submenus to ease the navigation to individual setup pages as well as to suggest the order in which to perform the various setup steps.
This section describes enhancements to Oracle Contact Center.
Header Configurability Prior releases had two separate folders for customer and contact information. These folders have been merged into a single folder. The merged customer and contact regions in the Contact Center enable better personalization and utilization of the space. There is no automatic upgrade of modifications you have made to the existing folders. You must reapply the changes to the merged folder.
Enhanced Orders and Install Base Tabs
The enhanced ordering flow process includes a new set of business functions (sub-tabs) within the Orders tab in the Contact Center that facilitates the quick creation of an order or update of an existing order when used in conjunction with the new Installed Base tab capabilities.
Expanded Contact Center capabilities include the ability to add or disconnect products and services (such as Telecommunications ordering) when used in conjunction with the new ordering capabilities in the Contact Center.
The enhanced Install Base tab enables the agent to take action on a selected item instance or set of instances (such as products/services) directly within the Install Base tab in the Contact Center. These actions range from the creation of a service request to updating product details for a specific product item instance or a set of instances. The list of actions is extensible, allowing the administrator to add to the list of pre-defined actions based on business needs. In addition, a search capability within the Install Base tab provides quicker identification of the product instances that need to be updated.
The entire functionality supported for Ordering and Install Base management in earlier releases is supported, however the UI navigation and flow may be different for specific functions.
Enhancements to the Multi-Org Access Control (MOAC) Migration
In earlier releases, data was not filtered by Operating Unit, allowing an agent full visibility into the customer data. Additionally, an agent could not choose the Operating Unit from the header.
In this release, MOAC compliance in the Contact Center ensures that the data is striped by the Operating Unit. The agent has visibility into all the transactions for all the Operating Units that they can access. The Operating Unit field is in the header Folder, and is hidden by default. The agent transacts (Create Orders, and so on) based on the Operating Unit set in the header. They can choose a different Operating Unit on the header for creating transactions if needed from the list of Operating Units that they can access.
The Oracle Customer Support Flexible Layout Regions provide added benefits for implementations, including:
Page content can be arranged in vertical orientation or horizontal orientation or a combination of both. You can also move content from one region to another.
A new graphical user interface allows administrators to see how a personalized page will appear and offers intuitive access to regions for personalization.
Other personalization tasks such as renaming, hiding and reordering regions are still performed using the previous personalization UIs that present regions in a hierarchical format.
Note: With the introduction of Flexible Regions, some personalization settings may not be preserved after the upgrade.
This release implements changes to Territory Administration and Role-based Access Control (RBAC).
The use of Forms to administer territories has been decommissioned and replaced by HTML-Excel UIs. All pre-existing Forms functionality is supported in this new model, with the exception of Resource Qualifiers and Territory Lookup. The Oracle Territory Manager Release 12 User Guide contains complete information.
In addition, the following changes have been implemented.
Prior to this release, Generate Territory Packages (GTP) and Generate Self-Service Territories (GSST) were used to re-compile territory definitions. In this release, GSST has been decommissioned, and GTP has been replaced by Synchronize Territory Assignment Rules (STAR). The Oracle Territory Manager Release 12 Implementation Guide contains complete information.
In this release, users must create territories using territory types, which are defined by transactions (Accounts, Leads, Opportunities, Customers, Service Requests, and so on). The territory type selected restricts the transactions and matching attributes available during the create flow.
Oracle Territory Manager seeds the following types:
Named Account - used to migrate named account territories. Shipped with all the Sales usage transaction types. Created for each operating unit.
General <usage name> - used for migrating geography territories and all other non-geographical or non-named account territories. Shipped with all the enabled matching attributes for the particular usage and with only the corresponding transaction types for each operating unit.
Geography - also used for migrating geography territories and all other non-geographical or non-named account territories. Shipped with all the geographic matching attribute values and all the Sales usage transactions types for each operating unit. Essentially, territories defined with only geographical matching attributes are migrated using the geographic type. If the territory is defined with both geographical and non-geographical matching attributes, the General territory type is used.
You can set up granular-level access type control for transaction types. In particular, you can grant read-only, full, or no access in Sales Usage for transaction types such as leads, opportunities, and quotes. Resources on 11.5.10 territories are granted full-access to the relevant transaction types.
Escalation territories are supported through the access flag at the resource level for Service. When adding a resource to a service territory, you can then change the access flag to Escalation for a given resource. There is no longer a need to create an additional Escalation territory.change the access flag to Escalation for a given resource. There is no longer a need to create an additional Escalation territory.
Prior to this release, Oracle Territory Manager provided custom matching attributes for some customers, as the out-of-the-box matching attributes shipped with the product did fully satisfy their business requirements.
In this release, customers must re-implement these custom matching attributes using the public API solution.
Prior to this release, Territory Administrators (CRM Administrator responsibility) could manage territories for all usages through the Forms UI. Users with Territory HTML Global Sales Administrator responsibility had access to the HTML administrator UIs (for Named Account and Geography Territory Groups), and users with the Territory HTML Sales User responsibility had access to the Territory Self-Service UIs.
In this release, Territory Manager uses the Role-based Access Control (RBAC) security model, with the following impact:
All users that access Territory Manager must have the Territory Management responsibility and an appropriate Territory role assigned.
| Role | Privileges |
|---|---|
| Sales Territory Administrator | Manage Sales territories |
| Service Territory Administrator | Manage Service territories |
| Field Service Territory Administrator | Manage Field Service territories |
| Service Contracts Territory Administrator | Mange Service Contract territories |
| Collections Territory Administrator | Manager Collection territories |
| Trade Management Territory Administrator | Manage Trade Management territories |
| Partner Management Territory Administrator | Manage Partner territories |
| Territory Manager Application Administrator | Access to all usages and can enable or disable matching attributes. Can run STAR for all usages. |
| Sales Team Search User | Access to the Sales Team Search page, with stand-alone access. Is inherited by users with the Sales Territory Administrator or the Sales Territory User role. |
| Sales Territory User | Access to the self-service Territory Manager application pages. |
Users can no longer access the Forms Territory Manager UIs with the CRM Administrator responsibility, but they can access the new HTML UIs.
The Territory HTML Global Sales Administrator responsibility and the Territory HTML Sales User responsibility still exist, but should be end-dated using the User Management responsibility.
Users must be granted the Territory Manager Application Administrator role in order to enable or disable matching attributes (formerly known as Qualifiers).
Changes for Oracle Field Service Advanced Scheduler are described in this section.
The Schedule Task window Preferences tab Assistance Level region offers three Interactive Scheduling options: Intelligent, Window to Promise, and Assisted. The Unassisted option available in prior releases is obsolete.
Advanced Scheduler supports customer incident and technician time zones. See Field Service (Core) in this appendix for more information.
Advanced Scheduler can plan and schedule service tasks that take longer than one work shift to complete. See Field Service (Core) in this appendix for more information.
See Field Service (Core) in this appendix.
You can define the times of day and days of the week when access to a customer, customer site, or customer site location is available. These access hours are automatically added to field service tasks generated by the Field Service Preventive Maintenance module, or they can be manually added in the Dispatch Center.
Advanced Scheduler treats task access hours as hard constraints, meaning that task arrival time must occur within one of the specified access time windows. Dispatchers have the ability to relax this constraint if Advanced Scheduler does not identify an acceptable schedule option.
Changes for Oracle Field Service (Core) are described in this section.
Oracle Field Service core and related products within the Field Service Suite support customer incident and technician time zones. User interfaces provide, where appropriate, fields for specifying the time zone at the technician’s location, as well as at the field service incident site. With this capability, call center agents, dispatchers, managers and administrators can communicate with customers and field technicians without having to make mental time zone conversions.
Oracle Field Service core and related products can plan and schedule service tasks that take longer than one work shift to complete. Advanced Scheduler searches for contiguous slots of scheduling options where a technician can perform the task on consecutive workdays. For example, Thursday, Friday, and Monday for a task having a planned effort of 24 hours duration, and the standard shift duration is 8 hours. When this criterion is met, Advanced Scheduler propagates a separate child task for each work shift required.
Subsequently, the dispatcher can use the Dispatch Center user interface to reschedule or reassign individual child tasks if, for example, an unplanned event causes the technician to be unable fulfill the tasks as scheduled, or cancel a child task if it is no longer needed due the technician completing the service early.
Service Request and Dispatch Center user interfaces make customer confirmation constraint information visible. A dynamic button label indicates whether customer confirmation of a task is required, not needed, or received. Click the Customer Confirmation button to open the Customer Confirmation window, and then update the status of the confirmation, if necessary. Controls are in place to prevent the commit or release of tasks to field technicians when confirmation is required but not received.
The following features enhance usability:
An Advance Find feature finds tasks matching combinations of more types of search criteria.
A Calendar HTML user interface now displays all of a technician’s assignments for a given day, week, or month.
The reworked Dispatch Center user interface makes the Plan Board and Gantt Chart views larger.
Technicians can drill down to task details from the Calendar.
Menu options from the main menu and context sensitive right-click menu options have been rationalized to provide similar and relevant options to enhance the user’s experience.
To support service on owned assets as well as customer products, a variety of enhancements have been made to Oracle Teleservice, Mobile Field Service, and Install Base:
In Release 11i, field service tasks could only be created when the service request incident address references a Trading Community Architecture (TCA) Party Site. In this release, Dispatch Center, Scheduler, Technician Portal and Mobile Field Service user interfaces and logic support creation of Field Service Tasks when the Incident Addresses is not associated to a TCA Party.
Enhancements to the Technician and Administrators Portals allow access to the Install Base user interface to update the record of the equipment being serviced. Note that this functionality is not available for Field Service Mobile Products in this release.
Changes for Oracle Mobile Field Service are described in this section.
In Release 11i, Mobile Field Service users had to be associated to the Mobile Field Service/Laptop responsibility to access Mobile Field Service Laptop. In this release, the Multiple Responsibility Model allows users to have different profile settings and different user interfaces. Regardless of the responsibility to which the user is associated, they have access to the Mobile Field Service Laptop application. Multiple technicians mapped with different responsibilities can be assigned to the same operating unit.
Mobile Field Service user interfaces have been redesigned using the User Interface XML (UIX) technology framework, which is based on Browser Look And Feel (BLAF) standards. Additionally, the Mobile Field Service Laptop application can be personalized at either site or responsibility level to show or hide data, reorder fields and regions, change prompts, and so on.
In Release 11i, Mobile Field Service: Wireless allowed technicians to create service request and follow-up tasks, but did not provide the ability to assign and schedule these tasks to themselves. This release provides the ability for technicians to assign tasks to themselves from mobile devices as well as provide a window of time for the customers to choose from. Using these scheduling capabilities, the technicians can either choose to work on the tasks right away or come back at a later time.
In Release 11i, field service tasks can only be created when the service request incident address references a Trading Community Architecture (TCA) Party Site. In this release, Dispatch Center, Scheduler, Technician Portal, and Mobile Field Service user interfaces and logic support the creation of Field Service Tasks when the Incident Addresses is not associated to a TCA Party.
Changes for Oracle Knowledge Management are described in this section.
You can perform exact phrase searches by using double-quotes (“ ”) operator. The Exact Phrase search option has been removed from the search option drop down menu. The default search operator has been changed “All of the keywords.” This change is limited to simple search only. The default search option for advanced search remains "Any of the Keywords," and is no longer defined by this profile.
Before this release, only the first 500 characters of note data were captured in the statement summary when trying to create a new solution from a service request. Now, complete note data is transferred over to the statement detail, and the first 2000 characters are kept inside the statement summary. An author can arrange the information between the statement summary and details. There is no impact on the existing solutions and statements created in the system.
New administration pages allow you to manage repositories available for simple search for a service provider. You can define custom repositories and associate the repositories with the appropriate contexts from the setup. Existing data defined in the system are upgraded accordingly.
In particular, the profile option “Knowledge: Simple search repository key” is now obsolete, and data defined in this profile (including the JTF advanced properties data) are migrated to different context mappings and custom repositories, if they exist. Data modified in the JTF properties is no longer honored by KM after the upgrade.
Autolinks have replaced the Note Token Rules. For any implementation that has already defined Note Token Rules for objects “Knowledge Base Solution” or “Knowledge: OA Solution,” and is being upgraded, no additional setup steps are required to use the existing rules, as they are upgraded as autolinks and autolink usage automatically.
The only change is that you should now use the Oracle Knowledge Management administration pages to view and update the setup. As a result, the administrator must have access to the Knowledge Base System Administration responsibility. Access to the Oracle Quality Online (OQO) administrator (DEMS Administrator) responsibility is no longer required. Data modified in OQO is no longer be honored by KM, and the setup screens for token rule are obsolete.
The KM administrator can submit and monitor concurrent requests directly from the KM menu, using a new request group that has been set up and assigned to the KM administrator.
The KM setup menu has changed due to the introduction of new setup screens and concurrent request ability. If you have customized the KM setup menu, you must incorporate these changes manually.