リリース11i
B25740-01
目次
戻る
次へ
| Oracle Daily Business Intelligenceインプリメンテーション・ガイド リリース11i B25740-01 | 目次 | 戻る | 次へ |
DBI for Service Contractsには、次のダッシュボードが用意されています。
サービス契約管理
サービス更改管理
「サービス契約管理」ダッシュボードには、新規ビジネス（元の失効下位明細とは関係ない新規下位明細）および更改（元の失効下位明細から更改された下位明細）の両方の契約が表示されます。「サービス更改管理」ダッシュボードに表示されるのは、更改に関する情報のみです。新規ビジネスの情報は表示されません。
この章では、契約サービス明細を明細と呼び、保証明細を下位明細と呼びます。
「サービス契約管理」ダッシュボードを使用すると、サービス契約記帳のステータス、新規ビジネスと更改ビジネス、取消および終了を表示できます。
「サービス契約管理」ダッシュボードは、次の目的の達成に役立ちます。
サービス・ビジネスの3つの状態（過去、現在、将来）の確認。
サービス契約の傾向を分析して、長期的な戦略上の意思決定と短期的な是正処理に対応。
サービス契約とそのライフ・サイクルのステータスを高いレベルで表示。要約された契約情報は、サービス契約の有効化、失効、終了の各活動の詳細、および表やグラフを提供する複数のレポートによって補足されます。
更改プロセスでの問題の早期検出による収益漏損の防止。詳細レポートを使用すると、最近失効または取り消された契約、および失効間近の契約に基づいて処理を実行できます。
パフォーマンス・インディケータとその推移の追跡。
年間値に基づく契約金額の比較。
サービス契約管理を使用すると、次の質問の回答に役立ちます。
期間中に失効した契約下位明細のステータスは? 失効した契約は正常に更改されたか、またはビジネスを失ったか? 更改は取り消されているか?
契約下位明細が終了する主な事由は? 終了した契約下位明細の値は? 契約下位明細が終了した日時は?
ビジネスの発生元は? 新規ビジネス有効化の値は? 更改ビジネスの値は?
「サービス契約管理」ダッシュボードは、次のアプリケーション領域を対象とします。
「サービス更改管理」ダッシュボードを使用すると、更改プロセスを管理し、その有効性を表示できます。
「サービス更改管理」ダッシュボードは、次の目的の達成に役立ちます。
期間累計で更改記帳のパフォーマンスを表示します。たとえば、記帳の累計、期間内に予測される記帳などです。
現期間内での更改の商談（または見積）を表示します。これらの更改には、現期間内で開始した更改または開始予定の更改、および累計された記帳済更改の一部があります。
記帳済更改の累計と作成された更改の商談の累計を比較することで、更改率を追跡します。
オープン商談（まだ記帳済でない、または取消済でない更改）および期限超過商談（選択した日付以前に開始日があり、まだ記帳済でない、または取消済でない更改）のステータスを追跡します。
サービス更改管理を使用すると、次の質問の回答に役立ちます。
自社の更改プロセスの効率は? これまでの更改記帳のステータスは? アップリフトのメジャーを使用した結果、記帳値は元の契約より高くなっているか、低くなっているか? すべての予測契約を記帳した場合、期末の記帳（予測記帳）は?
この期間に開始予定の更改で、自分の更改割当てを果たしているか?
部下の営業担当は、予定のレートで更改を記帳しているか?
更改は時間どおりに記帳されているか? オープン更改商談のバックログは? このバックログの遅延（開始日前に記帳されていない）部分は?
「サービス更改管理」ダッシュボードでは、次のアプリケーション領域からの情報が使用されます。
DBI for Service Contractsに用意されている各レポートとその計算方法の詳細は、『Oracle Daily Business Intelligenceユーザーズ・ガイド』を参照してください。
「サービス契約管理」のレポートには、契約の下位明細の情報が表示されます。表示される情報には、営業担当、営業単位、サービス品目、日付、金額、顧客などがあります。
異なる時点での契約下位明細ステータスに基づいて、契約を異なるレポートに表示できます。たとえば、「第3四半期」に終了した契約は、「終了詳細」レポートの「第3四半期」に表示されます。その契約の開始日が「第1四半期」にあり、「第1四半期」に過去のデータを表示している場合、その契約は、「有効化詳細」レポートの「第1四半期」に表示されます。
「サービス契約管理」ダッシュボードでは、次の日付を使用して、契約を適切なバケットに配置します。
ヘッダーから導出された取消日
ヘッダーから導出された署名（記帳）日
下位明細から導出された開始日
下位明細またはヘッダーから導出された終了日
下位明細から導出された満期日（契約は満期日の翌日に失効したとみなされます）
「サービス契約管理」ダッシュボードには、契約下位明細分析用に次のレポートが用意されています。
失効: 期間累計の失効済契約の詳細が表示されます。失効済契約のステータスは、「更改済」（対応する更改が記帳されている場合）、「オープン更改」（対応する更改が記帳されていない場合）、「取消済更改」（対応する更改が取り消されている場合）および「更改なし」（元の契約下位明細が更改される予定がなかった場合）のカテゴリに分類されます。
失効値分布: 失効値の詳細が失効契約カテゴリ別（「オープン更改」、「取消済更改」、「更改済」、「更改なし」）に表示されます。
「サービス更改管理」レポートには、契約の下位明細レベルの情報が表示されます。表示される情報には、営業担当、サービス品目、金額、日付、顧客などがあります。
様々な時点での契約下位明細ステータスに基づいて、契約を様々な時点の複数のレポート・バケット（「更改取消要約」レポートの取消済バケットなど）に表示できます。たとえば、「第1四半期」に入力された更改が、「第3四半期」に取り消されたとします。この更改は、「更改取消要約」レポートの「第3四半期」に取消済と表示されます。「第1四半期」に過去のデータを表示している場合、その更改は、「更改取消要約」レポートに取消済として表示されません。
「サービス更改管理」ダッシュボードでは、次の日付を使用して、契約を適切なバケットに配置します。
下位明細から導出された下位明細の作成日
ヘッダーから導出された予想クローズ日
ヘッダーから導出された取消日
ヘッダーから導出された署名（記帳）日
下位明細から導出された開始日
下位明細から導出された満期日
各レポートの詳細は、『Oracle Daily Business Intelligenceユーザーズ・ガイド』を参照してください。
「サービス更改管理」ダッシュボードには、更改記帳の分析用に次のレポートが用意されています。一部のレポートには、同じメジャーが表示されますが、メジャーの期間推移が異なります。たとえば、「更改記帳要約」レポートには、選択した期間でこれまでに署名された契約の記帳値が表示されます。「期間更改要約」レポートには、選択した期間に開始する契約の記帳値が表示されます。
次のレポートには、選択した期間のすべての更改に関する記帳、予測、取消およびアップリフトの値が表示されます。
更改記帳要約: 選択した期間でこれまでに作成された記帳値と予想済記帳（未記帳だが期間内に予想クローズ日のある契約更改）が表示されます。また、このレポートには、記帳されている更改の値が、元の契約より高いか、低いか（アップリフト）が表示されます。
遅延更改記帳: 期間累計の記帳済の更改契約が時間どおり（開始日以前）に記帳されたか、または遅延（開始日後）したかが表示されます。また、このレポートには、元の契約で指定されている猶予期間後に記帳された更改契約も表示されます。
遅延更改記帳年齢調べ: 遅延記帳の年齢分布が表示されます。たとえば、7日間の遅延の更改記帳は、すべて7日間の遅延日数バケットに表示されます。8日から15日までの間の遅延の更改記帳は、すべて8日から15日までの遅延日数バケットに表示されます。バケットはビジネス・ニーズにあわせてカスタマイズできます。詳細は、このマニュアルの「カスタム・バケットの設定」を参照してください。
次のレポートには、選択した期間に開始日があるすべての更改契約の更改、記帳、取消およびアップリフトの値が表示されます。
期間更改要約: 選択した期間に開始した契約更改下位明細の記帳および取消済値が、記帳日または取消日に関係なく表示されます。また、このレポートには、記帳されている更改の値が、元の契約より高いか、低いか（アップリフト）が表示されます。
次のレポートには、期間開始からこれまでの更改契約すべての更改値と記帳値が表示されます。
次のレポートには、入力済ステータスの状態にある更改契約すべての更改値が表示されます。
バックログ: システムのオープン商談（記帳も取消もされていない）の値が表示されます。このレポートには、契約の開始日までに記帳されていない遅延更改も表示されます。また、オープン商談の合計に対する遅延更改の比率も表示されます。
DBI for Service Contractsには、次の職責が用意されています。
サービス契約マネージャ
サービス営業マネージャ
Daily Service Contracts Intelligence
「サービス契約マネージャ」職責では、次のダッシュボードにアクセスできます。
サービス契約管理
サービス更改管理
HR管理 - 概要
費用管理
「サービス営業マネージャ」職責では、次のダッシュボードにアクセスできます。
サービス更改管理
サービス契約管理
HR管理 - 概要
費用管理
Daily Service Contracts Intelligence機能ベースの職責では、次のダッシュボードにアクセスできます。
サービス契約管理
サービス更改管理
DBI for Service Contractsで表示できるデータは、ユーザーがアクセス権を持っている営業グループのデータのみです。詳細は、「データの保護」を参照してください。
「費用管理」ダッシュボードと「HR管理 - 概要」ダッシュボードへのアクセスは、管理セキュリティに基づいています。ユーザーは、マネージャ階層の設定に基づいて、ユーザーの領域に関連するデータのみを表示できます。管理者階層内のマネージャではないユーザーは、「費用管理」ダッシュボードまたは「HR管理 - 概要」ダッシュボードのデータにアクセスできません。
あるダッシュボードから別のダッシュボードにナビゲートする際は、ダッシュボードに関連付けられている特定のセキュリティを使用して、ユーザーのアクセスが決定されます。
ロード要求セットの作成と発行やグローバル・パラメータの設定などの設定タスクを実行するには、Daily Business Intelligence for Service Contractsの各職責をユーザーに割り当てることに加え、Daily Business Intelligence管理者職責を実装担当に割り当てる必要があります。また、営業グループ階層を設定するには、「CRMリソース・マネージャ」職責を割り当てる必要があります。
DBI for Service Contractsでは次のディメンションが使用されます。一部のディメンションはOracle Daily Business Intelligence全体に共通しています。
このディメンションの説明は、このマニュアルの「時間ディメンション」を参照してください。
期間ディメンションでは、月、四半期および年の値が使用されます。
このディメンションの説明は、このマニュアルの「営業グループ・ディメンション」を参照してください。
「サービス契約管理」ダッシュボードと「サービス更改管理」ダッシュボードでは、営業グループ・ディメンションを使用して、営業グループ別にデータが表示されます。営業担当が属する営業グループは、契約に記録されています。そのため、ディメンションでは、「CRMリソース・マネージャ」に定義されている営業グループ階層を使用して、営業担当を営業グループに分類します。「営業グループ階層の設定」を参照してください。「営業担当の設定」も参照してください。
営業グループ・ディメンションには、無効化された営業グループと過去の営業担当（たとえば、会社を退職した営業担当）、および営業グループ間で異動した営業担当の過去の職階が含まれます。
このディメンションの説明は、このマニュアルの「営業単位ディメンション」を参照してください。
このディメンションの説明は、このマニュアルの「通貨ディメンション」を参照してください。
このディメンションを使用すると、通貨の表示に加えて、「サービス契約管理」ダッシュボードとレポートに、年間契約値を第1通貨または第2通貨のいずれかで表示できます。詳細は、『Oracle Daily Business Intelligenceユーザーズ・ガイド』を参照してください。
Oracle Daily Business Intelligenceで通貨換算および欠落通貨を処理する方法は、「通貨換算レート」を参照してください。
このディメンションの説明は、このマニュアルの「製品カタログ階層の設定」を参照してください。
このディメンションの説明は、このマニュアルの「品目ディメンション・レポート」の章を参照してください。
取消事由ディメンションでは、Oracle Service Contractsの契約ステータスから取消ステータス・コードをプルします。取消ステータス・コードは、契約の取消時に必要です。このコードはユーザーが定義します。
「取消事由と終了事由」を参照してください。
終了事由ディメンションでは、Oracle Service Contractsの下位明細終了事由から終了コードをプルします。終了事由は、下位明細の終了時に必要です。終了事由はユーザーが定義します。
「取消事由と終了事由」を参照してください。
有効化タイプ・ディメンションでは、有効化と保留中の有効化が、新規ビジネスか更改ビジネスかに基づいて分類されます。設定可能な値は、「新規ビジネス」と「更改」の2つです。
失効済契約タイプ・ディメンションでは、失効済契約が更改のステータスに従って分類されます。設定可能な値は、「更改済」、「オープン更改」、「取消済更改」および「更改なし」の4つです。
顧客分類ディメンションを使用して、論理グループまたは論理分類に基づいて顧客を分類します。このディメンションは、「サービス契約管理」のレポートで使用できます。「パーティ・マーケット分類タイプ」グローバル・パラメータで選択するカテゴリによって、顧客分類ディメンションで使用できる分類が決まります。
「パーティ・マーケット分類タイプ」グローバル・パラメータで使用可能なカテゴリは、クラス・カテゴリと呼ばれ、Oracle Trading Community Architecture（Oracle TCA）で作成されます。各クラス・カテゴリにはクラス・コードのセットが含まれている場合があります。クラス・コードは顧客に割り当てられます。「パーティ・マーケット分類タイプ」グローバル・パラメータでクラス・カテゴリを選択すると、対応する分類（クラス・コード）を顧客分類ディメンションで使用できます。
「パーティ・マーケット分類タイプ」グローバル・パラメータでは、一般タイプのクラス・カテゴリが表示されます。このカテゴリは非階層型であるため、複数のクラス・コードを割り当てることはできません。クラス・カテゴリとクラス・コードの詳細は、『Oracle Trading Community Architecture管理ガイド』を参照してください。
次の場合、DBI for Service Contractsでは、サービス契約が「未割当」顧客分類にグループ化されます。
Oracle TCAで顧客にクラス・コードが割り当てられていない場合、または割り当てられたクラス・コードが「パーティ・マーケット分類タイプ」グローバル・パラメータで指定したクラス・カテゴリに属していない場合。
「パーティ・マーケット分類タイプ」グローバル・パラメータでクラス・カテゴリが選択されていない場合。
このディメンションを使用できるのは詳細レポートのみです。顧客名はOracle Service Contractsの契約ヘッダー・レベルで指定します。指定方法は、「サービス契約オーサリング」ウィンドウの「要約」タブ・リージョンで名称を顧客パーティ役割に関連付けます。詳細は、『Oracle Service Contracts Concepts and Procedures』を参照してください。
顧客ディメンションに関連する実装に関する考慮事項については、「顧客の設定」を参照してください。
DBI for Service Contractsには、次のパフォーマンス測定が用意されています。これらは、「サービス契約管理」ダッシュボードと「サービス更改管理」ダッシュボードでキー・パフォーマンス・インディケータ（KPI）とも呼ばれています。
「サービス契約管理」ダッシュボードには、次のパフォーマンス測定があります。
「サービス更改管理」ダッシュボードには、次のパフォーマンス測定があります。
DBI for Service Contractsでは、営業グループ・セキュリティが使用されます。したがって、ユーザーが表示できるのは、アクセス権が与えられている営業グループのデータのみです。他の営業グループのデータはレポートに表示されません。
DBI for Service Contractsでは、「サービス」または「保証および延長保証」の契約からデータが取得されます。「サービス」、「保証」および「延長保証」の明細タイプが対象です。
顧客IDは、「サービス契約管理」と「サービス更改管理」の両方のダッシュボードで、OKC_K_PARTY_ROLES_B表のOBJECT1_ID1フィールドから収集されます。この場合、RLE_CODEフィールドは、CUSTOMER、LICENSEEまたはBUYERです。つまり、顧客IDは、「要約」タブの「パーティ」リージョンの契約から収集されます。顧客の役割タイプは、顧客、ライセンスまたは購買担当です。顧客IDに基づいて、顧客名がFII_CUSTOMERS_Vディメンション・ビューからフェッチされます。これは、各レポートに表示される顧客名です。（顧客名は「顧客」設定ウィンドウで定義します。このウィンドウには、Oracle Service Contractsからアクセスできます。）
営業担当IDは、「サービス契約管理」と「サービス更改管理」の両方のダッシュボードで、OKC_CONTACTS表のOBJECT1_ID1フィールドから収集されます。この場合、CRO_CODE（役割）は、次のロジックを使用して決定されます。
契約上の「供給元担当者」フィールドが参照されます。「OKS: 営業実績の使用可能化」プロファイル・オプションが「Yes」（リリース11.5.8）または「抽出」（リリース11.5.9）に設定されている場合は、「OKS: 供給元担当者ロール」プロファイル・オプションが参照されます。このプロファイル・オプションの値と一致する役割を持つ供給元担当者がその契約明細の営業担当として選択されます。
「OKS: 営業実績の使用可能化」が「No」（リリース11.5.8）または「ドロップ」あるいは「保持」（リリース11.5.9）に設定されている場合は、「営業担当」の役割に関連付けられている供給元担当者が選択されます。
Oracle Daily Business Intelligenceでは、契約から営業グループが取得されます。唯一の例外は、契約に営業担当も営業グループも含まれていない場合です。この場合、その契約はOracle Service Contractsでは営業グループ「未割当」に含まれないため、Oracle Daily Business Intelligenceで「未割当」バケットにまとめられます。DBI for Service Contractsでは、次の場合に、契約が「未割当」営業グループに割り当てられます。
営業担当が指定されているが、割り当られた営業担当の役割が設定時に定義されていない場合。
営業担当が契約に割り当てられ、有効な役割も設定されているが、設定時にどの営業グループにも関連付けられていない場合。
営業担当が契約に割り当てられ、有効な役割も設定されていて、設定時に「未割当」営業グループに関連付けられている場合。
営業担当を営業グループに関連付ける手順は、「営業グループ階層の設定」を参照してください。
注意: 大量の契約データがレポートの未割当明細に表示されるのを防ぐためには、次の方法を実行する必要があります。
主要営業担当が契約の供給元担当者として割り当てられていることを確認します。選択する供給元担当者の役割は、「営業担当」にしてください。
「未割当」以外の営業グループが契約の供給元担当者に関連付けられていることを確認します。
営業担当をOracle Service Contractsに入力すると、その営業担当の営業グループがデフォルト設定されます。契約内で営業担当の営業グループを更新する場合は、その営業担当が「メンバー」または「マネージャ」の役割を割り当てられている営業グループを選択する必要があります。「管理者」や「リーダー」の役割での営業グループ・レポートの実行はサポートされていません。
営業担当IDが取得されると、営業担当名は次のように取得されます。
「サービス契約管理」および「サービス更改管理」ダッシュボードのJTF_RS_RESOURCE_EXTNS_VL表のRESOURCE_NAMEフィールドから取得されます。この表には契約上の名称が格納されています。
「サービス契約管理」および「サービス更改管理」ダッシュボードのJTF_RS_RESOURCE_EXTNS表の「名称」フィールドから取得されます。この表には、「リソース」ウィンドウの名称が格納されています。詳細は、「営業グループ階層の設定」を参照してください。
1つの営業担当IDに複数の名称がある場合（たとえば、ID 555に営業単位1のJane Doeと営業単位2のJane M. Doeが設定されている場合）、JTF_RS_RESOURCE_EXTNS表でそのIDに割り当てられる名称は1つのみです。「サービス契約管理」と「サービス更改管理」ダッシュボードでは、営業グループ全体でデータが集計されます。したがって、特定のIDに対して表示される名称は1つです。その結果、ごくまれに、特に営業グループで、契約に入力したものと異なる名称がレポートに表示されることがあります。
適切なIDが取得されるようにするために、Oracle Service Contractsで次の設定を必ず完了してください。
「サービス契約マネージャ」職責を使用して「役割ソースの定義」ウィンドウにナビゲートします。
「パーティ役割」に「供給元」を選択します。
「担当者ソース」タブ・リージョンで、営業担当の担当者役割に次のデータが存在することを確認します。
担当者の役割: 営業担当
ソース: 営業担当
目的: 販売
これらのフィールドにこれらの値が設定されていないと、データは正しく表示されません。たとえば、「ソース」が「リソース」に設定されていると、前述の営業担当IDを取得するロジックでは、営業担当IDではなく、リソースIDが使用されます。この例では、システムでリソースIDを既存の営業担当IDと一致させようとします。その結果、誤った営業担当が表示されるか、または営業担当の名称が空白になります。
Oracle Service Contractsのレポートでは、取消事由がOKC_K_LINES_B表のSTS_CODEフィールドから取得されます。取消事由は、「サービス契約管理」ダッシュボードと「サービス更改管理」ダッシュボードの両方に表示されます。取消事由は、契約の取消時に必要です。
Oracle Service Contractsのレポートでは、終了事由がOKC_K_LINES_B表のTRN_CODEフィールドから取得されます。終了事由は、「サービス契約管理」ダッシュボードに表示されます。終了事由は、下位明細の終了時に必要です。
取消事由と終了事由はOracle Service Contractsで設定できます。
取消事由を設定する手順は、次のとおりです。
「サービス契約マネージャ」職責を使用して「ステータスおよび操作」ウィンドウにナビゲートします。
「ステータス・タイプ」に「取消済」を選択します。
「ステータス」セクションに取消事由を入力します。
詳細は、「ステータスおよび操作」ウィンドウの「ヘルプ」アイコンをクリックするか、『Oracle Contracts Coreインプリメンテーション・ガイド』を参照してください。
終了事由を設定する手順は、次のとおりです。
「サービス契約マネージャ」職責を使用して「参照」ウィンドウにナビゲートします。
参照タイプOKC_TERMINATION_REASONを使用して、終了事由を作成します。
参照コードの定義方法の詳細は、「参照」ウィンドウの「ヘルプ」アイコンをクリックするか、『Oracle Applicationsユーザーズ・ガイド』を参照してください。
DBI for Service Contractsでは、すべての契約に関する通貨情報が、取引通貨、機能通貨および第1通貨と第2通貨で格納されます。契約下位明細の機能通貨値の計算には、取引通貨から機能通貨への換算レートが使用されます。第1通貨または第2通貨の計算には、機能通貨から対応する通貨への換算レートが使用されます。
契約が機能通貨で作成されている場合、取引通貨から機能通貨への通貨換算レートは1となります。
機能通貨で作成されていない契約に通貨換算レートが含まれている場合は、そのレートが、取引通貨から機能通貨への換算に使用されます。
機能通貨で作成されていない契約に通貨換算レートが欠落している場合は、レートを計算するために、その契約にある換算日と換算タイプが使用されます。契約に換算日が含まれていない場合は、換算レートを検索するために、承認日（承認日が使用できない場合は契約作成日）が使用されます。契約に換算タイプが含まれていない場合は、Oracle Daily Business Intelligenceのグローバル第1換算レート・タイプが使用されます。
GL通貨換算表に換算日と換算レートが定義されていない場合は、ロードの実行要求が失敗したことを示すエラーが表示されます。後述の「通貨の欠落」を参照してください。
次のルールは、機能通貨から第1通貨またはオプションの第2通貨への換算に適用されます。このルールはOracle Daily Business Intelligence用に設定されています。第1通貨のみが設定されている場合、機能通貨金額は、次のルールを使用して第1通貨のみに換算されます。第1通貨と第2通貨の両方が設定されている場合は、次のルールを使用して2つの換算が実行され、一方の通貨金額が第1通貨で表示され、他方の通貨金額が第2通貨で表示されます。
機能通貨が第1通貨または第2通貨と同じ通貨の場合、機能通貨から第1通貨または第2通貨への通貨換算レートは1となります。
契約に換算日が含まれている場合は、レートを取得するために、その換算日とOracle Daily Business Intelligenceのグローバル換算レート・タイプが使用されます。機能通貨から第1通貨への換算には、第1レート・タイプが使用されます。機能通貨から第2通貨への換算には、第2レート・タイプが使用されます。
契約に換算日が含まれていない場合は、レートを取得するために、承認日（承認日が使用できない場合は契約作成日）とOracle Daily Business Intelligenceのグローバル換算レート・タイプが使用されます。機能通貨から第1通貨への換算には、第1レート・タイプが使用されます。機能通貨から第2通貨への換算には、第2レート・タイプが使用されます。
注意: ユーロとの間の換算では、契約の日付が1999年1月1日よりも前の場合、契約の換算日、承認日または作成日は使用されません。かわりに、換算日として1999年1月1日が使用されます。
Oracle Daily Business Intelligenceのすべての要求セットでは、通貨換算エラーはログに記録されます（Oracle Applicationsで「要求」ウィンドウの「ログの表示」を選択します）。DBI for Service Contractsでは、このログには、次の各項で説明する追加詳細が含まれます。
通貨の欠落: 取引通貨から機能通貨への換算、機能通貨から第1通貨への換算および機能通貨から第2通貨（設定されている場合）への換算のすべての換算の実行時に、欠落している通貨換算レートが表示されます。
取引から機能への換算詳細: 取引通貨から機能通貨への換算時に、通貨換算レートが欠落している契約が表示されます。
機能から第1グローバルへの換算詳細: 機能通貨から第1通貨への換算時に、通貨換算レートが欠落している契約が表示されます。
機能から第2グローバルへの換算詳細: 機能通貨から第2通貨（設定されている場合）への換算時に、通貨換算レートが欠落している契約が表示されます。
欠落している通貨レートは、ロードを実行する前に入力する必要があります。エラーに関する情報は、このマニュアルの「Daily Business Intelligenceの設定」の章を参照してください。通貨の詳細は、『Oracle Daily Business Intelligenceユーザーズ・ガイド』も参照してください。
次の表に、DBI for Service Contractsを実装する際の前提条件を示します。
| 前提条件 | 職責 |
|---|---|
| ハードウェア要件とソフトウェア要件の確認 | （適用なし） |
| Oracle Daily Business Intelligenceフレームワークの設定 | Daily Business Intelligence管理者 |
| 品目ディメンションの設定 | Daily Business Intelligence管理者 |
ハードウェアおよびソフトウェアのすべての前提条件については、OracleMetaLink から入手できる『About Oracle Daily Business Intelligence』の最新バージョンに詳細が記載されています。Oracle Service Contractsの正しいバージョンなどの前提条件については、このドキュメントで確認してください。
Oracle Daily Business Intelligenceフレームワークを設定します。詳細は、このマニュアルの「Daily Business Intelligenceの設定」の章を参照してください。特に、次の作業は必ず実行してください。
DBI for Service Contractsに関連するグローバル・パラメータを設定します。詳細は、このマニュアルの「グローバル・パラメータの設定」を参照してください。
「サービス契約管理」および「サービス更改管理」ダッシュボードを有効にします。詳細は、このマニュアルの「ダッシュボードの使用可能化」を参照してください。
カスタム・バケット・セットを設定します（オプション）。「遅延更改記帳年齢調べ」レポートの年齢バケットをカスタマイズするには、「サービス契約 - 遅延更改記帳年齢調べ」バケット・セットを再定義します。バケットのカスタマイズ手順については、このマニュアルの「バケットのカスタマイズ」を参照してください。
注意: Oracle Daily Business Intelligenceの設定時にエンタープライズ・カレンダを選択した場合は、このカレンダの期間に将来の活動日を持つ契約が含まれていることを確認してください。たとえば、「バックログ」レポートには、オープン商談（記帳済または取消済でないすべての更改）が表示されます。更改の開始日がエンタープライズ・カレンダに含まれている期間外の将来に発生する場合、オープン・バックログ値にはその更改が含まれません（更改はDBI for Service Contractsにロードされますが、時間ディメンションとの結合時にマテリアライズド・ビューで収集されません）。
DBI for Service Contractsのすべてのダッシュボードおよびレポートに対して品目ディメンションと製品カテゴリを設定します。詳細は、「品目ディメンション・レポート」の章を参照してください。
必要な前提条件をすべて満たした後は、DBI for Service Contractsの実装を開始できます。次の表に、実行する必要がある実装タスクのリストを示します。
| 手順 | 職責 |
|---|---|
| 1. 営業グループ階層の設定 |
|
| 2. 収集開始日の決定 | Daily Business Intelligence管理者 |
| 3. 「HR管理 - 概要」ダッシュボードおよび「費用管理」ダッシュボードへのアクセスのレビュー。この手順はオプションです。 | （複数の職責） |
「サービス契約管理」および「サービス更改管理」レポートの主要ビューの1つは営業グループ単位になっています。個別のレポートを表示する場合は、データを営業グループ別、あるいは営業単位、製品および製品カテゴリなどのその他のパラメータ別に表示できます。
営業グループは営業担当の集まりです。営業担当は契約の「供給元担当者」フィールドから取得されます（詳細は、「営業担当の設定」を参照）。営業グループ階層がない場合、レポートではすべての営業担当が「未割当」営業グループに配置されます。次の図は、営業グループ階層の例を示しています。
営業グループ階層には、少なくとも、他の営業グループまたは営業担当を含む最上位の営業グループ（2レベルの階層）を設定する必要があります。
営業グループのマネージャまたは管理者であるユーザーは（後述の手順を参照）、その営業グループに関連付けられたすべてのデータ、およびその営業グループに属する営業グループと営業担当に関連付けられたすべてのデータを表示できます。前述の図では、「USA営業」グループのマネージャや管理者は、Apt, Peter M.、「業種別アカウント」の営業担当および「キー・アカウント」の営業担当が作成したデータをすべて表示できます。
営業グループ階層の作成は、次の手順で構成されます。
営業グループを作成します。
営業担当（リソース）を営業グループに関連付けます。
次の手順は、Oracle Resource Managerを使用して実行します。詳細は、『Oracle Common Application Components User's Guide』を参照してください。
注意: ここで説明する営業グループ階層とその設定手順は、DBI for Salesの営業グループ・ディメンションが参照する営業グループ階層と設定手順と同じです。
さらに、作成される営業グループ階層はすべてOracle Daily Business Intelligenceの同じ営業グループ・ディメンションで処理され、階層の作成手順も同じです。
ただし、DBI for Service Contractsでは、DBI for Salesと異なる（追加の）営業グループ階層を定義できます。たとえば、DBI for Salesのレポートでは、DBI for Service Contractsがサービス契約の営業に使用するものとは異なる営業担当および営業グループを使用できます。
営業担当IDを取得するための設定が適切に実行されていることを確認します。「営業担当の設定」を参照してください。
営業グループを作成する手順は、次のとおりです。
「CRMリソース・マネージャ」職責を使用して「グループの定義」ウィンドウにナビゲートします。
グループの名称を入力します。
「使用場所」タブ・リージョンで、「営業およびテレセールス」のアプリケーション領域を選択します。
注意: 使用場所が「営業およびテレセールス」のグループのみがレポートに表示されます。レポートでは、「営業およびテレセールス」以外のグループに属する営業担当は「未割当」として表示されます。
必要に応じて、グループの親グループまたは子グループを選択します。
作成する営業グループごとにこの手順を繰り返します。
詳細は、『Oracle Common Application Components User's Guide』を参照してください。『Oracle Field Sales Implementation Guide』も参照してください。
Oracle Applicationsで営業担当が定義され（たとえば、従業員、パーティ、パートナまたは仕入先担当として）、ユーザー名に関連付けられていることを確認します。
「人事管理」職責を使用して「個人情報」ウィンドウにナビゲートします。
このウィンドウで、対象従業員のレコードが存在していることを確認します。
「システム管理者」職責を使用して「ユーザー」ウィンドウにナビゲートします。
「ユーザー」ウィンドウで、（「個人情報」ウィンドウの）この従業員がユーザーに関連付けられていることを確認します。
この従業員に関連付けるユーザーを問い合せるか、または作成し、ユーザーに対してこの従業員（個人）を入力します。
従業員を営業グループに割り当てる手順は、次のとおりです。
「CRMリソース・マネージャ」職責を使用して「インポートするリソースの選択」ウィンドウにナビゲートします。
1人以上の従業員を検索および選択し、「インポートの開始」を選択します。
表示される「リソース属性の設定」ウィンドウで、営業担当を作成し、営業実績タイプを割り当てます。
リソースを営業担当にする必要があります。詳細は、『Oracle Common Application Components User's Guide』および『Oracle Field Sales Implementation Guide』を参照してください。
リソースを保存し、「詳細」を選択します。
「役割」タブ・リージョンで、「役割タイプ」に「営業」を選択し、「役割」に「営業マネージャ」、「営業管理者」または「営業担当」を選択します。
注意: これらの役割を持つ従業員はすべて、グループのメンバーとしてレポートに表示されます。ただし、レポートにグループのデータを表示できるのは、「営業マネージャ」または「営業管理者」の役割を持つユーザーのみです。
「グループ」タブ・リージョンで、リソースを割り当てるグループを選択します。
「グループ・メンバー役割」セクションで、マネージャまたは管理者の権限を持つ役割を選択します。
「グループ・メンバー役割」セクションには、そのグループでの営業担当の役割が表示されます。レポートにグループのデータを表示できるのは、マネージャまたは管理者のみです。
変更内容を保存します。
これで、リソース（営業担当）は営業グループに割り当てられました。
DBI for Service Contractsの実装を完了した後は、「Daily Business Intelligenceの設定」の章の設定後の手順に進みます。これらの手順には、すべてのOracle Daily Business Intelligenceダッシュボードに対する初期ロードと増分リフレッシュの実行手順が含まれています。
「サービス契約管理」ダッシュボードまたは「サービス更改管理」ダッシュボードに対する初期ロードの要求を実行すると、次のパラメータの入力を求めるプロンプトが表示されます。
開始日（日付範囲の開始）
開始日の入力によって、この日付以降に作成または更新された契約または契約更改が収集されます。
終了日（日付範囲の終了。システム日付にデフォルト設定される）
開始日が正確に設定されていることを確認してください。設定した開始日が遅すぎると、契約が初期ロードに含まれないことがあるため、データが不正確になります。DBI for Service Contractsでは通常、開始日はOracle Daily Business Intelligenceに対して設定したグローバル開始日より前の日付に設定する必要があります（グローバル開始日は、Oracle Daily Business Intelligenceのすべてのレポートで使用される日付です。レポートには、この日付以降のデータは表示されますが、この日付以前のデータは表示されません）。
たとえば、1999年5月1日に署名（記帳）された契約があるとします。この契約は、1999年6月1日から開始し、1999年8月31日に終了しました。最後に更新されたのは1999年6月20日です。初期ロードの開始日を1999年8月1日に設定すると、この契約は収集されません。ロード時に収集する契約を決定する際は、契約の最後の更新日が使用されます。この例では、開始日を1999年6月20日に設定する必要があります。
注意: 初期ロードで開始日に使用する値を決定する場合は、収集する契約の最早作成日（前例では1999年5月1日）を使用します。最早作成日を使用すると、契約が確実に収集されます。
データを単純化し、パフォーマンスを向上させるために、要求では、グローバル開始日前に終了、取消または失効となっている契約は収集されません（この場合、グローバル開始日が開始日より後であることが前提です）。ただし、この2つの日付の間にある有効な契約は収集されます。これにより、有効な契約を表示する計算が正確であることが保証されます。
この手順は、「サービス契約マネージャ」職責と「サービス営業マネージャ」職責用です。「サービス契約管理」ダッシュボードと「サービス更改管理」ダッシュボードでは、この2つの職責に対して、次のダッシュボードへのリンクが提供されます。
HR管理 - 概要
費用管理
DBI for Service Contractsでは、これらのダッシュボードを実装する必要はありません。ただし、「サービス契約マネージャ」職責と「サービス営業マネージャ」職責には、「HR管理 - 概要」ダッシュボードと「費用管理」ダッシュボードへのリンクが含まれているため、これらのページでデータを表示できるのは、管理者階層内のマネージャであるユーザーのみです。
「HR管理 - 概要」ダッシュボードに使用できるドキュメントのリストは、このマニュアルのDaily Business Intelligence for Human Resourcesに関する項を参照してください。「費用管理」ダッシュボードの詳細は、このマニュアルの「Daily Business Intelligence for Financials」の章を参照してください。
ユーザーがこれらのダッシュボードへのリンクにアクセスできないようにするには、そのユーザーに「Daily Service Contracts Intelligence」職責を割り当ててください。この職責の場合は、「HR管理 - 概要」ダッシュボードと「費用管理」ダッシュボードへのリンクが表示されません。職責の詳細はこのマニュアルの「職責」を参照してください。
DBI for Service Contractsの前提条件および実装手順を完了した後は、他のインテリジェンス製品の実装に進むことができます。他のインテリジェンス製品を実装しない場合は、「Daily Business Intelligenceの設定」の章の設定後の手順に直接進んでください。特に、次の設定後の手順は必ず実行してください。
「サービス契約管理」ダッシュボードおよび「サービス更改管理」ダッシュボードに必要なすべての情報をロードするために初期要求セットを作成し、次に、この情報をリフレッシュおよび更新するために増分要求セットを作成します。詳細は、このマニュアルの「初期および増分要求セットの作成」を参照してください。
初期要求セットを実行します。詳細は、このマニュアルの「初期要求セットの実行」を参照してください。
ここでは、DBI for Service Contractsの保守と管理について説明します。
要求セット・ジェネレータを使用して作成した増分要求セットを使用して、「サービス契約管理」ダッシュボードまたは「サービス更改管理」ダッシュボードのデータをリフレッシュします。増分要求セットは毎日実行してください。要求セット・ジェネレータの詳細は、「概要」の章を参照してください。
DBI for Service Contractsのダッシュボードで、データを消去し、新規データで開始する必要がある場合は、初期要求を再発行します。初期要求によって時間ディメンションのデータの増分ロードが実行されます。
注意: DBI for Service Contractsファミリ・パックE（7.1）の実装またはアップグレードが完了した後は、「パーティ・マーケット分類のロード」をINITに設定して初期要求セットを実行する必要があります。その後、日次単位で増分要求セットを実行してください。
DBI for Service Contractsのダッシュボードのいずれかに対して増分要求セットを発行すると、次のパラメータの入力を求めるプロンプトが表示されます。
開始日（日付範囲の開始、最後に実行された要求の終了日にデフォルト設定される）
終了日（日付範囲の終了。システム日付にデフォルト設定される）
並行ワーカー数（ファクト表へのデータ収集時に同時に実行されるコンカレント・プログラムの数。デフォルトは1）
注意: 「開始日」パラメータと「終了日」パラメータによって、最後の契約更新日が収集の範囲内に入る日付範囲が定義されます。
コンカレント・プロセス（要求）によるデータの収集中に通貨換算エラーが発生すると、収集作業全体が失敗します。詳細は、「通貨換算レート」を参照してください。
注意: 第2通貨と年間通貨の設定はオプションです。DBI for Service Contractsの実装が完了した後でこれらの通貨を設定した場合、これらの通貨は設定後の増分要求によって収集された契約金額に対してのみ有効になります。すべてのデータに対してこれらの通貨を有効にする場合は、初期要求を再度実行します。たとえば、実装完了後に年間通貨を設定すると、増分要求セットによって収集された契約金額のみが年間通貨に設定されます。契約金額すべてを年間通貨に設定するには、初期要求を再度実行する必要があります。
営業グループ階層の設定または変更の手順は、「営業グループ階層の設定」を参照してください。営業グループ階層の変更後、階層の変更を有効にするために実行する必要があるコンカレント・プロセス（要求）のリストは、このマニュアルの「営業グループ階層の更新」の項を参照してください。
営業担当の情報にアクセス中に、その営業担当を営業グループ階層から削除するとレポートでエラーが発生します。次に例を示します。
「アフリカ営業」グループの営業担当Mr. Bakayoko Ibrihamaは、契約番号2081を更改しました。
「サービス更改管理」ダッシュボードにレポートを表示すると、契約番号2081は「アフリカ営業」グループの更改値に含まれています。
レポート内でMr. Bakayoko Ibrihama用の値へのリンクをクリックすると、Mr. Bakayoko Ibrihama用のデータを表示できます。
その後、「アフリカ営業」グループからMr. Bakayoko Ibrihamaを削除します。
レポート内でMr. Bakayoko Ibrihama用の値へのリンクをクリックすると、今度はエラーが発生します。
契約番号2081の値は、「アフリカ営業」グループの更改値または関連値にまだ含まれています。だたし、Mr. Bakayoko Ibrihama用のデータを表示しようとすると、一般レポート・エラーが発生します。
注意: 営業担当を営業グループから削除せずに、満期日を使用して、その担当の営業グループへの参加を失効させます（詳細は、『Oracle Common Application Components User's Guide』を参照）。
この項では、DBI for Service Contractsの実装と保守に関するトラブルシューティングのヒントを示します。
「未割当」営業グループに分類されている情報を表示できない場合
「未割当」営業グループに分類されている情報を表示するためには、「未割当」営業グループの「営業マネージャ」または「営業管理者」の役割にリソースが割り当てられている必要があります。営業グループへの役割の割当方法については、「営業グループへの営業担当（リソース）の関連付け」を参照してください。
顧客分類スキーマの変更後、初期および増分要求セットを実行しても、数値が要約および詳細レポートに集計されない場合
顧客分類スキーマの変更後は、「パーティ・マーケット分類のロード」要求のパラメータをINITに設定して初期要求を実行する必要があります。初期要求セットおよび増分要求セットの両方とも、「パーティ・マーケット分類のロード」要求のデフォルト値はINCREです。
