Oracle E-Business Suite リリース11iから12.2へのアップグレード・ガイド E51767-01

目次

前へ

次へ

Customer Relationship Managementのアップグレードの影響

この付録では、アップグレードが既存のOracle Human Resource Management System (HRMS)製品に及ぼす影響および機能変更が日常業務に及ぼす影響に重点を置いて説明します。この項では、HRMS製品ファミリの製品をアルファベット順に説明します。

この付録の内容は次のとおりです。

• ビジネスへの影響および機能変更
• Advanced Inbound
• Advanced Scheduler
• Customer Relationship Management
• Email Center
• Field Sales
• Field Service (Core)
• Incentive Compensation
• iSupport
• Knowledge Management
• Marketing
• Mobile Field Service
• One-to-One Fulfillment
• Order Capture/Quoting
• Partner Management
• Sales
• SalesおよびTelesales
• Service and Infrastructure
• TeleService
• Territory Manager

ビジネスへの影響および機能変更

アプリケーションのアップグレードにより、Oracle E-Business Suiteシステムの技術面と機能面の両方が変更されます。テクノロジ・スタックとファイル・システムが変更されるのみでなく、アップグレード後の既存製品の動作およびルック・アンド・フィールに影響する特定の変更も開始されます。これらの機能変更は、日常業務における製品の使用方法に影響します。

注意: この付録では、アップグレードで既存製品が変更される方法の一部を説明します。ここでは、My Oracle Supportの製品固有のリリース内容文書 (RCD) および情報転送文書 (TOI) に含まれる、このリリースに付属の新規機能および製品に関する情報を確認していることを前提としています。

この章では、アップグレードの機能面の説明がCustomer Relationship Management製品ファミリの製品別に構成されています。

Advanced Inbound

この項では、Oracle Advanced Inboundの変更点を説明します。

顧客参照

顧客参照機能変更点は、次のとおりです。

• リリース11iでは、顧客参照はサーバー・グループ・レベルで定義され、「コールセンターHTML設定UI」 (「分類」->「顧客参照」) からアクセス可能でした。このリリースでは、顧客参照を構成するには、「分類ルール」構成ページにナビゲートします (「管理」->「分類」->「ルール: 分類」タブ) 。

• アップグレード後は、すべての分類にデフォルト値「顧客参照なし」が設定されます。使用可能な分類ルールを使用するには、顧客参照を設定する必要があります。

基本テレフォニ

基本テレフォニ機能変更点は、次のとおりです。

• プロファイル・オプション「CCT: 基本テレフォニ: ACD ID」、「CCT: 基本テレフォニ: ACDパスワード」および「CCT: 基本テレフォニ: ACDキュー」が廃止され、削除されました。これらのプロファイル・オプションのデータは、次のようにCRMリソース・マネージャに移行しました。

  (N) 「CRMリソース・マネージャ」職責->「リソースの保守」>「リソース」 (B) 「リソース詳細」 (T) 「顧客対応センター」

• 既存のACDエージェント構成を表示するには、「CRMリソース・マネージャ」にナビゲートして目的のエージェントを選択します。ACDエージェント・パラメータは、シード済ミドルウェア (BASIC_MIDDLEWARE) 用に構成されています。

基本テレフォニで使用されるプロファイル・オプションには、他の変更点はありません。

アクティブ・モードでのルーティング

このリリースのOracle Advanced Inboundでは、インバウンド通話のアクティブ・モードでのルーティングはサポートされません。現在この機能を使用している場合は、拡張パッシブ・モードまたはパッシブ・モードを使用する必要があります。

注意: これらのモードのいずれかで実行するようにコールセンターを設定する方法の詳細は、『Oracle Advanced Inbound Implementation Guide』を参照してください。

Webコールバックには、引き続きアクティブ・モードでのルーティングを使用できます。

インストールの変更点

このリリースでは、インストール・プロセスが次のように変更されています。

• ieoicsm.classファイルが、$APPL_TOP/html/downloadから$INST_TOP/appl/download/ieo/に移動しました。

• 初期インストール後、あるいはCCT、IEOまたはUWQパッチの適用後に、次のコマンドを実行してieoicsm.classを再生成してください。

  		$INST_TOP/admin/scripts/ieo/ieozipmain.sh

ICSMサーバーの実行にAPPL_TOPインストール環境を使用していない場合は、セキュアFTPを使用して、ieoicsm.classを$INST_TOP/appl/download/ieo/からターゲットICSMノードのターゲット・ディレクトリにダウンロードします。

Advanced Scheduler

この項では、Oracle Advanced Schedulerの変更点を説明します。

「タスクの予定」ウィンドウ

「タスクの予定」ウィンドウの「作業環境」タブの「アシスト・レベル」リージョンには、対話形式の予定作成オプションとして「インテリジェント」、「時間枠」および「アシスト有」の3つが用意されています。以前のリリースで使用可能だった「アシスト無」オプションは廃止になりました。

事業所タイムゾーンのサポート

Advanced Schedulerでは、顧客障害および技術者タイムゾーンがサポートされています。詳細は、この付録の「Field Service (Core) 」 (ページB-7) を参照してください。

1シフトより長いタスク所要時間

Advanced Schedulerでは、完了までの所要時間が1作業シフトよりも長いサービス・タスクを計画し、予定を作成できます。詳細は、この付録の「Field Service (Core) 」 (ページB-7) を参照してください。

顧客確認要件

この付録の「Field Service (Core) 」 (ページB-7) を参照してください。

サイト・アクセス時間の制限

顧客、顧客サイトまたは顧客サイト事業所にアクセス可能な時間と曜日を定義できます。このアクセス時間は、Field Service Preventive Maintenanceモジュールで生成されるフィールド・サービス・タスクに自動的に追加されます。また、「派遣センター」で手動で追加することもできます。

Advanced Schedulerでは、タスク・アクセス時間はハード制約として処理されます。これは、タスク到着時間が指定のアクセス時間枠のいずれかで発生する必要があることを意味します。Advanced Schedulerで許容可能な予定作成オプションが識別されない場合、派遣担当はこの制約を緩和できます。

Customer Relationship Management

Customer Relationship Managementアプリケーション担当者は、この項の情報を十分に理解し、関連する変更内容に対応できるように、アップグレード開始前に適切な計画を作成する必要があります。

Email Center

ここでは、Email Centerの変更点、特定の機能固有の変更点に関する追加情報の参照先、変更された機能に対処するために必要な場合のある追加ステップを説明します。

Oracle Email Server単独

Email Centerでは、IMAP4準拠のすべてのメール・サーバーに接続し、メッセージをEmail Centerスキーマにダウンロードして処理できます。この変更には、新しい設定画面と管理画面が関連付けられています。

Eメール・アカウントの管理: 管理者は、Email Center管理者コンソールで使用可能な新しいアカウント管理画面を使用して、Eメール・アカウント・パラメータを直接定義できます。

シナリオ1: Eメール・メッセージは、現行リリースのEmail Center実装の一部として社内メール・サーバーから、次のようにリダイレクトされます。

• リリース11.5.9および11.5.10: アカウントmyermsaccount@mycompany.comには、Email Centerセルフ・サービス管理コンソールで作成されたmyermsaccount@oesmailserver.comにEメール・メッセージをルーティングするリダイレクト・ルールがあります。

• リリース12: 管理者は、アカウント管理画面を使用してEメール・アカウント詳細を直接定義できます。

  注意: どちらのシナリオでも、アップグレードの一環としてデータ移行を計画している場合は、myermsaccount@oesmailserver.comなどのEメール・アカウントがEメール・データとともに新規構成表に移行し、「無効」とマーク付けされます。このアカウントに新しいアカウント管理画面からアクセスし、必要に応じてアカウント・プロパティを更新し、リリース12のフローで動作するように有効化できます。

ダウンロード・プロセッサ: Email Centerのダウンロード・プロセッサは、構成した間隔で実行し、接続してEメールをEmail Centerスキーマにダウンロードする中間層サービスです。Eメール・アカウント用にEmail Centerで定義した構成データを使用して、そのEメール・アカウントに接続し、Eメール・メッセージをダウンロードしてさらに処理できます。

Eメール・アカウントがEmail Centerで定義されている場合、システムではそのアカウントに「Oracle処理済」および「Oracle再試行」フォルダが作成されます。メッセージがダウンロードされると、Eメールのメタデータとコンテンツの両方が、管理者によりパージされるまでEmail Centerスキーマに残ります。

データ移行ツール

Email Centerの新規バックエンド・サーバー・アーキテクチャにより、新しい構成表とトランザクション表が導入されています。以前のリリースのEmail Centerはすべて新規アーキテクチャへの移行パスを必要とするため、このリリースには一連のデータ移行ツールが付属しています。そのコンポーネントは次のとおりです。

• ダウンロード・プロセッサ - 移行モード: このモードでは、ダウンロード・プロセッサはOracle Email ServerにあるEメール・アカウントに接続し、すべてのフォルダからリリース12のスキーマにEメールを取り出すことができます。

• Email Center移行コンカレント・プログラム: これらのプログラムは、Eメール移行データとOracle Customer Interaction Historyの調整を制御し、Eメールを適切なメッセージ・ストアに移動します。

• 移行コンソール: Email Center管理コンソールのこれらの画面を使用して、管理者はデータ移行をモニターし、移行ステータスについて助言もできます。

カスタム・ワークフロー・プロセス

Oracle Email Serverに基づいて格納されたメッセージからローカル・メッセージ・ストアに基づいたメッセージへの切替の一環として、付属の工場出荷時ワークフローではEmail Serverに基づいたデータへの参照をすべてキーから削除するように変更されています。工場出荷時には使用できない特定のフローを実装するために使用していた顧客ワークフロー・フックがある場合は、コードを再検証してテストし、この変更を反映するよう必要に応じてコードを更新する必要があります。

ライブ・メッセージの移行

アップグレード前の処理を伴うEメール・メッセージをライブ・メッセージと呼びます。移行後、Email Centerエージェントは移行前の状態のライブ・メッセージにアクセスし、適切な処理を実行できます。通常、メッセージはエージェントによる取得待ちキューにあるか、すでにエージェントが取得して「受信ボックス」で待機中になっています。ライブEmail Center実装でこの状態になっているデータの割合は、サイトにあるEメールの数量に応じて異なります。

ライブ・メッセージの移行が完了するまでは、Email Centerを使用しないでください。停止時間はごく短く、ライブ状態になっているEメールの数に応じて異なります。

メッセージ履歴の移行

Email Centerで処理済のEメール・メッセージは、Oracle Email Serverメッセージ・ストアに保持され、監査および顧客対応の追跡のためにアクセスされます。本番で使用されていた実装の場合、この状態になっているデータの割合が高くなることがあります。

「Email Center移行」コンカレント・プログラムには、「履歴Eメールの締め日」パラメータが用意されており、デフォルトは30日です。移行する履歴データの量を指定できます。移行しない履歴データは、Email Centerアプリケーションで表示できなくなります。ただし、大量の履歴データを移行すると、移行処理に長時間かかることがあります。

注意: 移行対象となるEメール・メッセージの数は、移行の処理時間に影響します。処理時間を短縮するには、履歴Eメール・データの締め日を指定します。ライブ・メッセージの移行が完了した後は、履歴データの移行がバックグラウンドで実行されている間にEmail Centerを使用できます。検索結果の件数が減少することはありますが、処理の完了後は正確な結果が得られます。

Field Sales

リリース11.5.10はOracle Field Sales (Sales Online) のターミナル・リリースでした。このリリースでは、Field Salesは廃止になっています。この製品を使用している場合は、Oracle Salesアプリケーションにアップグレードする必要があります。この変更は、全ユーザーに機能上の影響をもたらします。Field Sales (Sales Online) のデータをOracle Salesに移行する前に、機能分析を完了しておくことをお薦めします。

注意: 詳細は、この付録の「営業実績の移行」 (ページB-26) を参照してください。

Field Service (Core)

この項では、Oracle Field Service (Core) の変更点を説明します。

事業所タイムゾーンのサポート

Oracle Field Service CoreおよびField Service Suite内の関連製品では、顧客障害および技術者タイムゾーンがサポートされています。該当する場合、ユーザー・インタフェースでは、技術者の事業所のタイムゾーンと、フィールド・サービス障害サイトのタイムゾーンを指定するフィールドが提供されます。この機能により、コールセンターのエージェント、派遣担当、マネージャおよび管理者は、タイムゾーンの切替を気にせずに顧客やフィールド技術者と通信できます。

1シフトより長いタスク所要時間

Oracle Field Service Coreおよび関連製品では、完了までの所要時間が1作業シフトよりも長いサービス・タスクを計画し、予定を作成できます。Advanced Schedulerでは、技術者が連続する稼働日にタスクを実行できる予定作成オプションの連続スロットが検索されます。たとえば、木曜、金曜および月曜にはタスクの計画従事が24時間で、標準シフト期間が8時間であるとします。この基準が満たされていれば、Advanced Schedulerでは必要な作業シフトごとに個別の下位タスクが伝播されます。

その後、派遣担当は「派遣センター」ユーザー・インタフェースを使用して、計画外イベントが原因で技術者がタスクを予定どおり履行できなくなった場合などに個別の下位タスクの予定を再作成または再割当したり、技術者がサービスを早期に完了したために不要になった場合は下位タスクを取り消すことができます。

顧客確認要件

「サービス要求」および「派遣センター」ユーザー・インタフェースにより、顧客確認制約情報が参照可能になっています。動的ボタン・ラベルは、タスクの顧客確認が必須か、不要か、受入済かを示します。「顧客確認」ボタンをクリックして「顧客確認」ウィンドウを開き、必要に応じて確認ステータスを更新します。確認が必須だが受入済でない場合は、タスクがフィールド技術者にコミットまたはリリースされないように制御が移ります。

操作性

次の機能により操作性が強化されています。

• 拡張検索機能では、より多数のタイプの検索基準の組合せと一致するタスクが検索されます。

• カレンダHTMLユーザー・インタフェースには、指定した日、週または月に関する技術者の割当がすべて表示されます。

• 改造された「派遣センター」ユーザー・インタフェースでは、「計画ボード」および「ガント・チャート」ビューが大きくなっています。

• 技術者は、「カレンダ」からタスク詳細にドリルダウンできます。

• メイン・メニューのメニュー・オプションとコンテキスト依存の右クリック・メニュー・オプションが合理化され、ユーザー操作を強化するために類似または関連するオプションが提供されます。

資産に対するサービス

所有資産と顧客製品に対するサービスをサポートするために、Oracle Teleservice、Mobile Field ServiceおよびInstall Baseに様々な機能拡張が行われました。

• リリース11iでは、フィールド・サービス・タスクを作成できるのは、サービス要求の障害所在地でTrading Community Architecture (TCA) のパーティ・サイトが参照されている場合のみでした。このリリースでは、「派遣センター」、「スケジューラ」、「技術者ポータル」および「移動フィールド・サービス」の各ユーザー・インタフェースとロジックにより、障害所在地がTCAパーティに関連付けられていない場合のフィールド・サービス・タスク作成がサポートされています。

• 技術者ポータルと管理者ポータルの機能拡張により、「導入ベース」ユーザー・インタフェースにアクセスしてサービス対象設備のレコードを更新できます。この機能は、このリリースのField Service Mobile製品では使用できないことに注意してください。

Incentive Compensation

この項では、Incentive Compensationの変更点を説明します。

工場出荷時

工場出荷時のIncentive Compensationには一連の職責が付属しており、それぞれに適切なビジネス・フロー権限が付与されています。したがって、リリース11iで既存または作成済のメニューおよび職責は失効しています。アップグレード完了後に、既存ユーザーに新しい職責を割り当てる必要があります。

次の表に新しい職責を示します。

グローバル管理: 複数組織アクセス管理

複数組織アクセス管理 (MOAC) により、1つの職責で複数の営業単位にアクセスできます。「インセンティブ報酬管理者」は、営業単位ごとに個別の職責でログインしなくても、複数の営業単位のシステム設定を構成できます。OICの報酬マネージャは、営業単位ごとに個別の職責でログインしなくても、複数の営業単位の取引とリソースを問い合せて変更できます。

Oracle Territory Managerとの統合

リリース11iでは、Sales Crediting and Allocationでテリトリ割当エンジン (TAE) を使用するにはテリトリ・クオリファイアのマッピングを設定する必要がありました。このリリースのOICでは、このマッピングが自動的に提供され、収集後プロセスの一環として2つのマッピング・オプションの一方を使用して表にデータが移入されます。

オプション1: このリリースで提供されるシード済のOIC属性とテリトリ・クオリファイアのマッピングを使用します。

オプション2: 引き続き既存のOIC属性とテリトリ・クオリファイアのマッピングを使用します。

注意: この2つのオプションの使用方法の詳細は、『Oracle Territory Manager Functional Upgrade』を参照してください。

新しいコンカレント・プログラムを使用した収集計画の作成

Territory Managerでは、コンカレント・プログラム「テリトリ割当ルールの同期化」 (STAR) を実行できます。これは、既存のGTPコンカレント・プログラムを置き換えます。このコンカレント・プログラムを合計モード、増分モードおよび有効日モードで実行できます。合計モードと増分モードの動作は、すべてのコンシューマ・アプリケーションについてリリース11iと同じです。有効日モードは、OICにのみ適用可能です。

「テリトリ割当ルールの同期化」 (STAR) コンカレント・プログラムでは、次のパラメータを使用できます。

• 使用

• 取引タイプ

• 実行モード

• 開始日

• 終了日

• デバッグ・フラグ

「テリトリ割当ルールの同期化」コンカレント・プログラムにより作成された事前処理API (動的パッケージ) は、廃止になっています。

マルチレベル・マーケティング産業のサポート

追加の設定パラメータにより、マルチレベル・マーケティング要件がサポートされます。たとえば、各OIC取引の積上レベルを追跡できます。

計画要素の設定には、積上計算オプションが含まれます。計画要素が構成されている場合は、積上取引のコミッションを計算するかどうかを選択できます。計算対象として全リソースまたはマネージャのみを選択できます。

プロファイル・オプションの変更

一部の共通のシステム・レベル・プロファイル・オプションは、「OIC管理者構成ワークベンチ」で変更できるパラメータとして定義されています。OIC管理者は「構成ワークベンチ」を使用して、これらのパラメータを手動で設定する必要があります。

リリース11iの次のプロファイル・オプションは、変更されています。

*このオプションをアップグレード中に「取引別支払」を「Y」に変更する場合は、すべての支払実行とワークシートが「支払済」になっていることを確認する必要があります。確認しないと、データが破損してリソースを使用できなくなります。

用語の変更

次の表に、用語変更を示します。

廃止になった機能

「予算実績」レポートが「達成要約」レポートで置き換えられ、Sales Force Planningモジュールおよび「所得プランナ」は廃止になりました。My Oracle Support (Doc ID: 338866.1) を参照してください。

注意: 「所得プランナ」の予定報酬計算機能では、OIC実装済の報酬計画に用意されている多数の設定が取り込まれません。そのため、営業パイプラインの予想が不正確になる可能性があります。

iSupport

iSupportアプリケーション担当者は、この項の情報を十分に理解し、関連する変更内容に対応できるように、アップグレード開始前に計画を作成する必要があります。

登録

このリリース以前にカスタム・ユーザー・タイプを定義しており、それをiSupportの登録中に引き続き利用する場合は、アップグレード後にユーザー・タイプ・キーをAOL参照表の関連iStore参照タイプに手動で関連付ける必要があります。このタスクを完了しないと、iStoreではユーザー・タイプを判別できず、登録ユーザーは登録ページで使用できなくなります。参照タイプは次のとおりです。

• 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

たとえば、シード済のiSupportユーザー・タイプIBU_INDIVIDUALは、iStore参照タイプIBE_UM_INDIVIDUAL_USER_TYPESにマップされます。「参照」フォームを使用して、カスタマイズした全ユーザー・タイプに対して同じ処理を実行する必要があります。

複数パーティの設定

1. プロファイル設定:

   • ユーザー・プロファイル名: Oracle iSupport: 複数パーティ・アクセスの有効化

   • 説明: 複数パーティが有効化されているかどうかをチェックするプロファイル

   • プロファイル値: 「Yes」または「No」

   • デフォルト値: No

     注意: プロファイル・オプションは「Yes」に設定し、複数パーティ機能を有効化する必要があります。

2. 職責:

   管理者および主要ユーザーに対して「パーティ・アクセス」メニューを表示するには、次のようにナビゲートし、Oracleフォームを開始する必要があります。

   (N) 「システム管理者」->「職責」

   • 管理者:

     「iSupport管理者 - JTF管理」の職責を検索します。「メニュー除外」タブで機能IBU_PARTY_ACCESS_FNを削除し、保存します。

   • 主要ユーザー:

     「iSupport主要ユーザー」の職責を検索します。「メニュー除外」タブで機能IBU_PARTY_ACCESS_FNおよびIBU_SWITCH_PARTY_FNを削除し、保存します。

   • ビジネス・ユーザー:

     「iSupportビジネス・ユーザー」の職責を検索します。「メニュー除外」タブで機能IBU_SWITCH_PARTY_FNを削除し、保存します。

3. 権限の割当:

   • iSupport管理者:

     IBU_SYSTEM_ADMINロールを選択し、次の権限を割り当てます。

     • IBU_PARTY_USERS

     • IBU_SEARCH_PARTY

     • IBU_PARTY_ACCESS

     • IBU_ASSOCIATE_PARTY

     • IBU_PARTY_ACCOUNT_ACCESS

     • IBU_PARTY_ACCOUNTS_VIEW

     • IBU_PARTY_ACCESS_VIEW

     • IBU_PARTY_REMOVE_VIEW

     • IBU_DEFAULT_PARTY_VIEW

       注意: ロールIBU_SYSTEM_ADMINがiSupport管理者に割り当てられていることを確認します。割り当てられていない場合は、iSupport管理者に割り当てます。

   • iSupport主要ユーザー:

     IBU_PRIMARY_USERロールを選択し、次の権限を割り当てます。

     • IBU_PARTY_USERS

     • IBU_SEARCH_PARTY

     • IBU_PARTY_ACCESS

     • IBU_ASSOCIATE_PARTY

     • IBU_PARTY_ACCOUNT_ACCESS

     次の権限は、主要ユーザーに割り当てる場合と割り当てない場合があります。このような権限は、「パーティ・アクセス」ページの「アカウント」、「パーティ・アクセス」、「削除」、および「デフォルト・パーティ」列の表示に使用されます。たとえば、IBU_PARTY_ACCOUNTS_VIEW権限が主要ユーザーに付与されていない場合、その主要ユーザーはアカウント列を表示できません。

     • IBU_PARTY_ACCOUNTS_VIEW

     • IBU_PARTY_ACCESS_VIEW

     • IBU_PARTY_REMOVE_VIEW

     • IBU_DEFAULT_PARTY_VIEW

       注意: ロールIBU_PRIMARY_USERがiSupport主要ユーザーに割り当てられていることを確認します。割り当てられていない場合は、iSupport主要ユーザーに割り当てます。

   • iSupportビジネス・ユーザーの場合:

     IBU_Business_USERロールを選択し、次の権限を割り当てます。

   • IBU_SWITCH_PARTY

     注意: IBU_SWITCH_PARTY権限はビジネス・ユーザーにのみ割り当てます。

複数パーティの検索設定

前述の設定に加え、次のリージョン属性も有効化する必要があります。

選択したオプションのパーティ属性をデフォルトで表示する場合は、次のリージョン属性を有効化する必要があります。

Knowledge Management

この項では、Oracle Knowledge Managementの変更点を説明します。

検索演算子

二重引用符 (“ ”) 演算子を使用して完全一致フレーズ検索を実行できます。「フレーズに完全一致」検索オプションは、「検索オプション」ドロップダウン・メニューから削除されました。デフォルトの検索演算子は「すべてのキーワード」に変更されています。この変更は単純検索のみに限定されています。拡張検索のデフォルトの検索オプションは「いずれかのキーワード」のままであり、プロファイル・オプション「知識: デフォルトの検索方法」では定義されなくなりました。

サービス要求のノートからの説明文の作成

このリリースまでは、サービス要求から新しい解決の作成を試行した場合に、説明文要約で取得されるのはノート・データのうち最初の500文字のみでした。現在のリリースでは、完全なノート・データが説明文詳細に転送され、最初の2000文字が説明文要約に保持されます。作成者は、説明文の要約と詳細の間で情報を配置できます。システムで作成された既存の解決と説明文への影響はありません。

検索管理

新しい管理ページを使用して、サービス・プロバイダの単純検索に使用可能なリポジトリを管理できます。カスタム・リポジトリを定義して、設定からの適切なコンテキストに関連付けることができます。システムで定義済の既存データはそれに応じてアップグレードされます。

特に、プロファイル・オプション「知識: 単純検索リポジトリ・キー」は廃止され、このプロファイルに定義されたデータ (JTF拡張プロパティ・データなど) は、別のコンテキスト・マッピングおよびカスタム・リポジトリが存在する場合はそちらに移行します。JTFプロパティで変更されたデータは、アップグレード後はKnowledge Managementで受け入れられなくなります。

自動リンク管理

自動リンクはノート・トークン・ルールで置き換えられています。すでにオブジェクト「知識ベース解決」または「知識: OA解決」のノート・トークン・ルールを定義済で、アップグレードする実装の場合、既存ルールは自動リンクおよび自動リンク使用として自動的にアップグレードされるため、それを使用するための追加の必須設定ステップはありません。

唯一の変更点は、設定を表示および更新するためにOracle Knowledge Managementの管理ページを使用する必要があることです。そのため、管理者は知識ベース・システム管理職責へのアクセス権が必要です。Oracle Quality Online (OQO) 管理者 (DEMS管理者) 職責へのアクセス権は不要になりました。OQOで変更されたデータはKnowledge Managementで受け入れられなくなり、トークン・ルールの設定画面は廃止になっています。

コンカレント要求のアクセス

Knowledge Management管理者は、設定されて自分に割り当てられた新しい要求グループを使用して、Knowledge Managementのメニューからコンカレント要求を直接発行してモニターできます。

設定メニュー

Knowledge Managementの設定メニューは、新しい設定画面とコンカレント要求機能の導入に伴って変更されています。Knowledge Managementの設定メニューをカスタマイズした場合は、これらの変更内容を手動で取り込む必要があります。

Marketing

前のリリースのキャンペーンはリリース12に移行されます。製品レポートが正しいことを確認するには、この移行が必要です。既存のキャンペーンの基礎となるデータは変更されませんが、次のキャンペーン属性のデータはこの移行によって影響を受けます。

キャンペーン名: 「キャンペーン」で特定のバージョンが識別された場合は、「キャンペーン名」は[キャンペーン名]_[キャンペーン・バージョン]となります。キャンペーン・バージョンは廃止されており、同一のキャンペーン名が複数存在することになります。すべてのキャンペーンを一意に保つため、該当するバージョンは、「キャンペーン名」と「バージョン」を使用して導出した名前のキャンペーンに移行する必要があります。バージョンが複数でないキャンペーンは変更されません。

キャンペーン - 製品カテゴリ関連: 「製品カテゴリ」が「単一製品カタログ」に移行またはアップグレードされていることを確認します。既存のキャンペーンと関連付けられている「製品カテゴリ」は移行では変更されません。このため、これらのカテゴリの主要フラグはそのまま残ります。

キャンペーン - 製品関連: 既存の「キャンペーン」に関連付けられた「製品」が「単一製品カタログ」に属していることを確認します。「キャンペーン」に関連付けられおり、「単一製品カタログ」に含まれない製品を識別します。このような製品がある場合は、その製品を手動で「単一製品カタログ」に含めます。その後、この製品を「キャンペーン」-「製品」関連付けスキーマで更新します。

キャンペーン - 製品関連 (主要フラグ) : キャンペーンが製品カテゴリまたは製品に関連付けられている場合、製品関連は主要として設定されません。このため、キャンペーンと関連付けられている製品カテゴリまたは製品がある場合、ユーザーが別の製品カテゴリまたは製品関連を主要として選択しなければ、これを主要関連としてマークします。

詳細は、Oracle Marketingインプリメンテーション・ガイド リリース12.2 (Oracle Marketing Implementation Guide Release 12.2) を参照してください。

Mobile Field Service

この項では、Oracle Mobile Field Serviceの変更点を説明します。

複数職責

リリース11iのMobile Field Serviceユーザーは、Mobile Field Service Laptopにアクセスできるように「Mobile Field Service/ラップトップ」職責に関連付ける必要がありました。リリース12.2では、複数職責モデルによりユーザーが異なるプロファイル設定および異なるユーザー・インタフェースを使用できます。ユーザーは、関連付けられている職責に関係なくモバイル・フィールド・サービス・ラップトップ・アプリケーションにアクセスできます。異なる職責にマップされた複数の技術者を同じ営業単位に割り当てることができます。

ラップトップ・ユーザー・インタフェース

Mobile Field Serviceのユーザー・インタフェースは、ブラウザのルック・アンド・フィール (BLAF) 標準に基づくユーザー・インタフェースXML (UIX) テクノロジ・フレームワークを使用して再設計されました。また、モバイル・フィールド・サービス・ラップトップ・アプリケーションをサイトまたは職責レベルでパーソナライズして、データの表示と非表示の切替え、フィールドとリージョンの並替え、プロンプトの変更などを行うことができます。

セルフ・スケジュール

リリース11iのMobile Field Service: Wirelessでは、技術者はサービス要求および追跡タスクを作成できましたが、これらのタスクを技術者自身に割り当ててスケジュールする機能は用意されていませんでした。リリース12.2では、技術者がモバイル機器から自分にタスクを割り当てる機能と、顧客に選択させる期間のウィンドウが用意されています。これらのスケジュール機能を使用すると、技術者はタスクをただちに処理するか後から処理するかを選択できます。

非TCAパーティの障害所在地

リリース11iでは、フィールド・サービス・タスクを作成できるのは、サービス要求の障害所在地でTrading Community Architecture (TCA) のパーティ・サイトが参照されている場合のみでした。リリース12.2では、「派遣センター」、「スケジューラ」、「技術者ポータル 」および「モバイル・フィールド・サービス」の各ユーザー・インタフェースとロジックにより、障害所在地がTCAパーティに関連付けられていない場合のフィールド・サービス・タスク作成がサポートされています。

One-to-One Fulfillment

One-to-One Fulfillmentでは、一括Eメール要求資料送付のパフォーマンスが向上しています。サーバーではJavaプロセスに複数のスレッドが使用されるようになり、新しいサーバー・レベル・フラグが追加されました。

• インストール時に、資料送付サーバーにより一括Eメール要求が新しいマルチスレッド資料送付プロセスを介してルーティングされます。このプロセスは、「JTO: サーバー: マルチスレッド資料送付の使用」プロファイル・オプションを更新するとオフにできます。

• 一括Eメール要求の顧客対応履歴の記録は、主要処理スレッドから移動し、このリリースではバッチ・ルーチンが使用されます。「顧客対応履歴バルク・プロセッサ」コンカレント・プログラムを定期的に実行するようにスケジュールする必要があります。

• 新しい「JTO: 資料送付要求のパージ」コンカレント・プログラムを使用すると、古い資料送付要求の関連データをパージできます。このコンカレント・プログラムでは複数のデータベース・ワーカーが使用されるため、多数の行を処理できます。実行日に資料送付要求の相対年齢を設定すると、このコンカレント・プログラムを定期的に実行するようにスケジュールできます。

• 資料送付サーバーでは、Eメール・ヘッダーにマージ可能な「表示名」、「差出人」および「返信」の値を指定できます。Eメール・サーバーの設定画面で「表示名」のデフォルト値を定義する必要があります。

• バウンスバック機能は、sendmail構成を変更してもしなくても動作します。バウンスしたメッセージを単一のバウンスバック・アカウントにダイレクトするために、sendmail構成を更新する必要はなくなりました。

Order Capture/Quoting

この項では、Oracle Order Capture/Quotingの変更点を説明します。

Trading Community Architectureとの統合

Trading Community Architectureでは、次の処理が変更されています。

• 「検索して選択: 顧客」フローでのパーティ、アカウントおよび所在地の一括選択は、TCA共通コンポーネントではサポートされません。

  アカウント - パーティを選択すると最も古いアカウント (存在する場合) がデフォルト設定されます。パーティに複数のアカウントが存在する場合は、パーティの選択後にアカウントを変更する必要があります。

  所在地 - 検索結果には、全所在地のかわりに識別所在地のみが表示されます。この所在地は、パーティの選択時には選択されません。パーティの選択後に、この所在地を選択する必要があります。パーティ、アカウントおよび担当をまとめて選択できます。

  担当 - 担当情報は表示されません。パーティの選択後に担当を選択する必要があります。そのかわりに、パーティの選択時に所在地と担当がデフォルト設定されるように、デフォルト・ルールを設定する方法もあります。

• 「検索して選択: 所在地」フローでは担当と所在地の表示や一括選択ができなくなりました。ただし、所在地の検索結果をフィルタして、現行の見積先/出荷先/請求先の担当の所在地は表示できます。

• TCAコンポーネントでは、標準テキスト・ボックスの値リストはサポートされていません。したがって、見積先/出荷先/請求先の顧客担当と出荷先/請求先顧客は消去できなくなりました。

廃止になった機能と処理

• 以前のリリースで作成した保存済検索は、アップグレード後は使用できません。アップグレード後のシステムで再作成する必要があります。

• 以前のリリースの選択可能列と見積詳細のサイドバー・メニューの変更内容を、Oracle Applicationsのパーソナライズを使用して再実装する必要があります。

• Oracle ReportsはOracle XML Publisherで置き換えられています。カスタマイズした「見積の印刷」レポートは、Oracle XML Publisherを使用して再作成する必要があります。

• 製品検索では、非Intermedia検索はサポートされません。

• リリース11iで使用していた「明細値引」列は、新しい選択可能列「調整金額」で置き換えられています。値引が率のみでなく金額で可能になったため、「明細値引」列は不要になりました。

• アカウント番号にはドリルダウンを使用できません。Oracle Sales (ASN) では、「顧客詳細」ページにアカウント情報が表示されなくなりました。

Partner Management

パートナおよびパートナ・ユーザー (オプション)

Oracle Partner Managementの既存の顧客を前のリリースからリリース12.0にアップグレードする場合は、インストール後のステップとして「PV: パートナ・タイプ移行」コンカレント・プログラムを実行する必要があります。このコンカレント・プログラムを実行しない場合、既存のパートナの主要パートナ・タイプが空白になります。また、これらのパートナは一連の検索結果の一部として返されません。

詳細は、Oracle Partner Managementインプリメンテーションおよび管理ガイド　リリース12.2 (Oracle Partner Management Implementation and Administration Guide Release 12.2) のパートナ・ユーザーに関する項 (Partner Users) を参照してください。

パートナ・タイプ値の移行 (オプション)

以前のリリースでは、複数のパートナ・タイプを単一パートナに割り当てることができました。リリース12.0では、それぞれのパートナに割り当てられるパートナ・タイプは1つのみです。Oracle Partner Managementの以前のリリースからアップグレードする場合は、パートナ・タイプ・データを完全に移行するために一定の管理機能を実行する必要があります。

PV_PARTNER_TYPE_RANKING参照表にそれぞれの既存パートナ・タイプのランクの数値を移入します。この表は一部のパートナ・タイプとランク・データでシードされており、ベンダーはシード済の値を追加および変更できます。「PV: パートナ・タイプ移行」コンカレント要求ではこの参照表を使用して、パートナの既存のタイプを評価し、最上位のタイプ (最低値のタイプ) を選択することで、単一タイプを各パートナに割り当てます。

たとえば、パートナが現在、再販業者とOEMのパートナ・タイプの両方に割り当てられており、再販業者に割り当てられている値がOEMの値より低い場合、パートナの新規タイプは再販業者になります。ベンダーは、VADタイプを除き、それぞれのパートナ・タイプをランク付けする必要があります。VADはベンダーが指定したランクに関係なく、常に最上位のパートナ・タイプとみなされます。

パートナ・タイプのランクを設定した後、「PV: パートナ・タイプ移行」コンカレント・プログラムを実行して新規のランクを既存パートナに割り当てます。このプログラムは次のいずれかのモードで実行できます。

• 評価 (デフォルト値) : 「評価」を選択してパートナ・データを変更せずにプログラムを実行します。これにより、「パートナ・タイプ」に指定したランクに基づいてパートナ・データを変更した場合の変化を把握できます。

• 実行: 「実行」を選択してパートナ・タイプをアップグレードし、基礎となるデータベースに対する変更を保存します。

また、既存のパートナタイプの「上書き」を選択できます。この値は2つのいずれかを選択できます。

No: 「 No」に設定すると、パートナ・レコードの既存のパートナ・タイプは上書きされません。この値は、なんらかの理由でコンカレント・プログラムが失敗し、再度実行する必要がある場合に役立ちます。再実行では、最初に処理されたパートナ・レコードは更新されず、未処理のパートナ・レコードのみが更新されます。値を「No」に設定すると、プログラムをより効率的に実行できます。

コンカレント・プログラムではそれぞれのパートナの元のパートナ・タイプと新規パートナ・タイプを含む、移行に関する情報を示すログ・ファイルが生成されます。

詳細は、Oracle Partner Managementインプリメンテーションおよび管理ガイド リリース12.2 (Oracle Partner Management Implementation and Administration Guide Release 12.2) のパートナ・タイプ値の移行に関する項 (Migrating Partner Type Values) を参照してください。

外部営業チーム・データの移行 (オプション)

Oracle Partner Managementの以前の実装では、パートナ組織が商談、引合、および営業チームから削除された後、商談、引合、顧客営業チームにパートナ担当を作成できました。リリース12以降、パートナ担当はパートナ組織からアクセスされるため、パートナ組織が削除された場合、担当にはアクセスできません。

コンカレント・プログラムPV - 外部営業チームの移行を実行して、パートナ組織が削除された後も、パートナ担当がオブジェクトと関連付けられている場合に、パートナ組織が商談、引合、顧客営業チームに再度関連付けられたことを確認します。コンカレント・プログラムはリリース12へのアップグレード・プロセス中、Oracle SalesとOracle Partner Managementの統合プロセスの一部として、またその後に定期的に実行する必要があります。

詳細は、Oracle Partner Managementインプリメンテーションおよび管理ガイド リリース12.2 (Oracle Partner Management Implementation and Administration Guide Release 12.2) の外部営業チーム・データの移行に関する項 (Migrating External Sales Team Data) を参照してください。

Sales

この項では、Oracle Salesの変更点を説明します。

Oracle Sales OnlineからOracle Salesへのユーザーのアップグレード

このリリースでは、すべてのSales OnlineユーザーがOracle Salesに移行し、次のように職責が割り当てられます。

• 「Sales Onlineユーザー」職責を持つ全ユーザーに「営業ユーザー」職責が割り当てられます。

• 「Sales Onlineマネージャ」職責を持つ全ユーザーに「営業マネージャ」 (営業DBI) 職責が割り当てられます。

• 「Sales Onlineスーパーユーザー」職責を持つ全ユーザーに「営業管理者」職責が割り当てられます。

Sales Onlineで使用していた全プロファイル・オプション (「MO: 営業単位」など) は、Oracle Salesの対応するプロファイル・オプションに移行します。

Sales Onlineで使用していたFND参照タイプはすべて、Oracle Salesの対応する参照タイプに移行します。

SalesおよびTelesales

この項では、Oracle SalesとOracle Telesalesに共通の変更点を説明します。

営業実績の移行

Oracle Salesでは、商談に複数の商談明細を使用し、明細ごとに異なる営業担当が収益実績を受領すると指定できます。ただし、1つの商談明細の全収益実績を受領する営業担当は1人のみです。

このリリースでは、同じ商談明細に複数の営業担当が収益実績を受領すると指定されている商談がアップグレードされ、その明細の収益実績を受領する営業担当は確実に1人のみとなります。単一の商談明細に複数の営業担当が指定されている商談がアップグレード対象となります。

Oracle Salesと同様に、Oracle Telesalesでも、商談明細ごとに収益実績の受領者として営業担当が1人のみサポートされます。

Service and Infrastructure

この項では、リリース12におけるOracle Service and Infrastructureの機能拡張を説明します。

• eAMサービス要求の処理の改善

  このリリースの前までは、「件名」タブなど、すべての品目インスタンス関連フィールドはeAMサービス要求に使用できませんでした。このリリースでは、これらのフィールドと「件名」タブをeAMサービス要求で使用できるようになり、サービス組織を識別するための新規フィールド (「保守組織」) が追加されています。このフィールドはeAMサービス要求に必須であり、プロファイル・オプションまたは資産定義からデフォルト設定できます。

• XML Publisherのサービス要求レポート

  以前のリリースのHTMLサービス要求レポートは、新しいXML Publisherレポートで置き換えられています。使用するテンプレート、言語および出力形式など、様々なパラメータを指定してレポートを生成できるようになりました。

• 手数料に関する複数組織アクセス管理 (MOAC) への移行

  このリリースより前のリリースでは、手数料機能を使用して、有効な全営業単位の手数料明細を作成できました。手数料がOrder Managementに発行されると、個別の手数料明細が作成された営業単位へのアクセス権が付与されているかどうかが検証されました。このアクセスは、営業単位ごとにOracle Human Resourcesのその他情報タイプ (E.I.T.) 付加フレックスフィールドで保守および検証されていました。これらのセキュリティ付与は全ユーザーおよび職責間で共有されていたため、ユーザー・グループごとに異なるセキュリティ・ポリシーはサポートされていませんでした。

  このリリースでは、MOACインフラストラクチャへの移行により、このアクセス管理がOracle Human Resourcesのセキュリティ・プロファイル機能に移動しています。各セキュリティ・プロファイルを単独で定義してアプリケーション職責に関連付けることができ、ユーザー・グループごとに異なるセキュリティ・ポリシーのサポートが可能になります。現在E.I.T.を使用している顧客は、セキュリティ・ポリシーを新しいセキュリティ・プロファイル機能に移行する必要があります。

  注意: 詳細は、『Oracle TeleService Implementation Guide』を参照してください。

  さらに、次の機能も拡張されています。

  • サービス要求デフォルト営業単位プロファイル・オプション

    リリース11iでサービス要求の営業単位のデフォルト設定に使用していた「MO: 営業単位」プロファイル・オプションは、新しい「サービス: サービス要求デフォルト営業単位」プロファイル・オプションに移行します。

  • サービスのデフォルト営業単位

    このリリースでは、「営業単位」フィールド (デフォルトでは非表示) が「サービス・デフォルト営業単位」に名称変更されています。値は「サービス: デフォルト営業単位」プロファイル・オプションから導出され、サービス要求レコード上でスタンプされます。

• 自動割当プロセス

  リリース11iでは、サービス契約と導入ベースで除外リソースを指定できましたが、これらのリソースは優先リソースとは異なり、サービス要求とサービス要求タスクの自動割当プロセス中には使用されませんでした。このリリースでは、Territory Managerから戻されたリソースが自動割当プロセスにより検証され、サービス契約と導入ベースで「除外」として定義されたリソースがフィルタ・アウトされます。

  注意: 除外として定義されたリソースと自動割当プロセスを使用するリソースは、サービス要求およびサービス要求タスクの所有者候補として選択されません。

• 「割当マネージャ」UI

  リリース11iの「割当マネージャ」UI (「サービス要求」フォームからアクセス可能) には、指定した営業単位についてTerritory Managerで有効化されている照合属性 (旧称クオリファイア) のみが公開されていました。このリリースでは、どの営業単位で有効化されているかに関係なく、使用可能な任意の照合属性を使用できます。

  次の両方の条件が満たされている場合、この変更により割当が変更される可能性があります。

  • 「割当マネージャ」UIを割当プロセスの実行に使用している場合。この変更は、自動割当プロセスのビジネス・ロジックには影響しません。

  • 異なる営業単位で異なる照合属性 (クオリファイア) セットを有効化していた場合。

  「割当マネージャ」UIには全営業単位間の照合属性が表示されるため、サービス要求に関連付けられているものとは異なる営業単位に対して有効化された照合属性を選択できます。このような照合属性をServiceのテリトリ設定で使用していると、「割当マネージャ」UIには、指定した営業単位の照合属性のみが使用されていた場合とは異なる候補リソース・セットが表示されることがあります。

• 設定メニュー

  リリース11iでは、すべてのサービス要求設定は単一メニュー (「サービス要求」) で実行していました。このリリースでは、個別設定ページに容易にナビゲートでき、各種設定ステップの実行順序がわかるように、各種の設定がサブメニューにカテゴリ化されています。

TeleService

Oracle TeleServiceではサービス要求の処理が改善され、「連絡センター」の機能と構成オプションが追加され、「顧客サポート」の新機能が追加されています。

Contact Center

この項では、Oracle Contact Centerの機能拡張を説明します。

• ヘッダー構成可能性以前のリリースでは、顧客および担当情報に2つの個別のフォルダがありました。この2つのフォルダが単一フォルダにマージされています。「連絡センター」にマージされた顧客および担当リージョンを使用すると、領域を適切にパーソナライズして利用できます。既存のフォルダの変更内容は自動的にアップグレードされません。マージされたフォルダに変更内容を再適用する必要があります。

• 拡張された「受注」および「導入ベース」タブ

  拡張された受注処理フロー・プロセスでは、「連絡センター」の「受注」タブに新しいビジネス関数 (サブタブ) セットが組み込まれており、新しい「導入ベース」タブの機能と併用すると、すばやく受注を作成したり既存の受注を更新できます。

  拡張された「連絡センター」機能には、新しい受注機能と併用している場合に、製品とサービス (通信受注など) を追加または接続解除する機能などがあります。

  拡張された「導入ベース」タブを使用すると、エージェントは「連絡センター」の「導入ベース」タブで選択した品目インスタンスまたはインスタンス・セット (製品/サービスなど) に対して処理を直接実行できます。これらの処理は、サービス要求の作成から、特定の製品品目インスタンスまたはインスタンス・セットに関する製品詳細の更新まで広範囲に渡っています。処理リストは拡張可能であり、管理者はビジネス・ニーズに基づいて事前定義済の処理リストに追加できます。また、「導入ベース」タブの検索機能を使用すると、更新を必要とする製品インスタンスをすばやく識別できます。

  以前のリリースで受注および導入ベース管理用にサポートされていた機能全体がサポートされますが、特定の機能についてUIナビゲーションとフローが異なっている場合があります。

• 複数組織アクセス管理 (MOAC) の移行の機能拡張

  以前のリリースでは、データは営業単位でフィルタされないため、エージェントは顧客データを完全に参照できました。また、エージェントはヘッダーから営業単位を選択できませんでした。

  このリリースでは、「連絡センター」のMOAC準拠により、データは営業単位で確実にストライプ化されます。エージェントは、アクセス権が付与されている全営業単位の全取引を参照可能です。エージェントは、ヘッダーに設定された営業単位に基づいて取引 (受注の作成など) を実行します。このフィールドはデフォルトでは非表示ですが、エージェントがアクセス権のあるエージェント単位を切り替えるために表示可能です。

Customer Support

Oracle Customer Supportのフレキシブル・レイアウト・リージョンは、実装に次のようなメリットをもたらします。

• ページ・コンテンツを垂直方向または水平方向、あるいはその両方の組合せで配置できます。また、コンテンツをリージョン間で移動することも可能です。

• 新しいグラフィカル・ユーザー・インタフェースにより、管理者はパーソナライズしたページの表示を確認でき、パーソナライズするリージョンへの直感的なアクセスが可能になります。

  リージョンの名称変更、非表示または並替えなど、その他のパーソナライズ・タスクの実行には、リージョンを階層形式で表示する以前のパーソナライズUIを引き続き使用します。

  注意: フレキシブル・リージョンの導入により、アップグレード後は一部のパーソナライズ設定が保持されない可能性があります。

Territory Manager

このリリースでは、テリトリ管理とロール・ベース・アクセス管理 (RBAC) に対する変更が実装されています。

テリトリ管理

テリトリ管理におけるFormsの使用は廃止になり、HTML-Excel UIで置き換えられています。この新しいモデルでは、「リソース・クオリファイア」と「テリトリ参照」を除き、既存のForms機能がすべてサポートされています。詳細は、Oracle Territory Manager Release 12 User Guideを参照してください。

また、次の変更が実装されています。

廃止になったコンカレント・プログラム

以前のリリースでは、「テリトリ・パッケージの生成」 (GTP) と「セルフ・サービス・テリトリの生成」 (GSST) を使用してテリトリ定義を再コンパイルしていました。このリリースでは、GSSTが廃止され、GTPは「テリトリ割当ルールの同期化」 (STAR) で置き換えられています。詳細は、Oracle Territory Managerリリース12 インプリメンテーション・ガイドを参照してください。

テリトリ・タイプ

このリリースでは、ユーザーは取引別 (アカウント、引合、商談、顧客、サービス要求など) に定義されたテリトリ・タイプを使用してテリトリを作成する必要があります。選択したテリトリ・タイプにより、作成フローで使用可能な取引と照合属性が制限されます。

Oracle Territory Managerでは、次のタイプがシードされています。

• 指定アカウント - 指定アカウントのテリトリを移行するために使用します。すべての営業使用取引タイプが付属しています。営業単位ごとに作成します。

• 一般 <使用名> - 地理テリトリと他のすべての非地理または非指定アカウント・テリトリの移行に使用します。特定の使用に対して有効化された全照合属性と、各営業単位に対応する取引タイプのみが付属します。

• 地理 - 地理テリトリと他のすべての非地理または非指定アカウント・テリトリの移行に使用します。各営業単位のすべての地理照合属性値とすべての営業使用取引タイプが付属します。実際には、地理照合属性のみで定義されたテリトリの移行には、「地理」タイプを使用します。テリトリが地理照合属性と非地理照合属性の両方で定義されている場合は、「一般」テリトリ・タイプを使用します。

アクセス・レベル

取引タイプ用に粒度レベルのアクセス・タイプ管理を設定できます。特に、引合、商談および見積などの取引タイプに対して、営業使用で読取り専用アクセス、全アクセスまたはアクセス権限なしを付与できます。リリース11.5.10のテリトリには、関連取引タイプへの全アクセスが付与されます。

エスカレーション・テリトリ

エスカレーション・テリトリは、「サービス」のリソース・レベルでアクセス・フラグを介してサポートされます。サービス・テリトリにリソースを追加すると、指定したリソースのアクセス・フラグを「エスカレーション」に変更できます。エスカレーション・テリトリを追加作成する必要はなくなりました。

カスタム照合属性

以前のリリースのOracle Territory Managerでは、製品付属の工場出荷時照合属性でビジネス要件が完全には満たされていなかったため、一部の顧客向けにカスタム照合属性が用意されていました。

このリリースでは、顧客はパブリックAPIソリューションを使用して、これらのカスタム照合属性を再実装する必要があります。

ロール・ベース・アクセス管理 (RBAC)

以前のリリースでは、テリトリ管理者 (「CRM管理者」職責) はForms UIを介してすべての使用のテリトリを管理できました。「テリトリHTMLグローバル営業管理者」職責を持つユーザーは、HTML管理者UI (「指定アカウント」および「地理」テリトリ・グループの場合) に、「テリトリHTML営業ユーザー」職責を持つユーザーはテリトリ・セルフ・サービスUIにアクセスできました。

このリリースのTerritory Managerでは、ロール・ベース・アクセス管理 (RBAC) セキュリティ・モデルを使用しており、次のような影響があります。

• Territory Managerにアクセスする全ユーザーが「テリトリ管理」職責を持ち、適切なテリトリ・ロールが割り当てられている必要があります。

  ロール	権限
  営業テリトリ管理者	営業テリトリの管理。
  サービス・テリトリ管理者	サービス・テリトリの管理。
  フィールド・サービス・テリトリ管理者	フィールド・サービス・テリトリの管理。
  サービス契約テリトリ管理者	サービス契約テリトリの管理。
  回収テリトリ管理者	回収テリトリの管理。
  取引管理テリトリ管理者	取引管理テリトリの管理。
  パートナ管理テリトリ管理者	パートナ・テリトリの管理。
  テリトリ・マネージャ・アプリケーション管理者	すべての使用へのアクセスであり、照合属性を有効化または無効化できます。すべての使用に対してSTARを実行できます。
  営業チーム検索ユーザー	スタンドアロン・アクセスによる「営業チーム検索」ページへのアクセス。「営業テリトリ管理者」または「営業テリトリ・ユーザー」ロールを持つユーザーが継承します。
  営業テリトリ・ユーザー	セルフ・サービスTerritory Managerアプリケーション・ページへのアクセス。

• ユーザーは「CRM管理者」職責でForms Territory Manager UIにアクセスできなくなりましたが、新しいHTML UIにアクセスできます。

• 「テリトリHTMLグローバル営業管理者」職責と「テリトリHTML営業ユーザー」職責は引き続き存在しますが、「ユーザー管理」職責を使用して終了する必要があります。

• ユーザーが照合属性 (旧称クオリファイア) を有効化または無効化するには、「テリトリ・マネージャ・アプリケーション管理者」ロールを付与されている必要があります。

Copyright © 1996, 2013, Oracle and/or its affiliates.All rights reserved.