1. 経費の実装
  2. トラベル・パートナ統合の前提条件の設定方法

トラベル・パートナ統合の前提条件の設定方法

トラベル・パートナは、従業員に出張サービスを提供するオンライン予約プロバイダまたは旅行代理店です。Oracle Fusion Expensesでトラベル・パートナおよび予約サイトを設定する前に、会社で次の前提条件ステップを実行する必要があります:

  • トラベル・パートナを選択します。

  • 予約サイトを構成します。

  • 出張ポリシーおよびポリシー違反を構成します。

  • 従業員のアクセス方法を決定します。

  • 従業員を設定します。

トラベル・パートナの選択

会社が従業員の出張ニーズに基づいてトラベル・パートナを選択し、従業員の所在国でそのトラベル・パートナによって提供される出張予約サポートを選択します。選択すれば、特定の国でのみトラベル・パートナのサービスを使用することもできます。

Expensesでは、GetThereトラベル・パートナとの統合がサポートされています。また、RESTサービスを使用した他のトラベル・パートナとの統合もサポートされています。Expensesは、組織の要件を満たすために複数のトラベル・パートナと統合できる柔軟性を備えています。Expensesで設定できるシナリオをいくつか次に示します:

  • 米国の従業員についてはGetThereと統合し、アジア太平洋地域の従業員については別のトラベル・パートナと統合します。

  • 中東地域についてはあるサードパーティ・トラベル・パートナと統合し、残りの地域については別のトラベル・パートナと統合します。

  • 米国についてはGetThereと統合し、中東地域およびアジア太平洋地域についてはそれぞれ異なるトラベル・パートナと統合します。

複数のトラベル・パートナと統合するときに注意する必要がある点をいくつか次に示します:

  • 組織に対して複数のGetThere統合を設定することはできません。

  • トラベル・パートナ統合間で国または雇用割当の重複がないようにする必要があります。したがって、1人の従業員に適用可能な予約サイトは1つのみである必要があります。

予約サイトの構成

予約サイトは、従業員のグループ向けに構成された、トラベル・パートナの予約ツールのインスタンスです。会社では、トラベル・パートナのシステムで構成された1つ以上の予約サイトが必要になることがあります。事業に応じて、複数の予約サイトが必要になることもあります。

  • 会社が複数の国や地域で事業を行っている。

  • 会社の出張ポリシーが従業員のジョブ・ロールに応じて異なる。

    たとえば、エグゼクティブ・バイス・プレジデント以上の管理レベルの従業員は高級ホテルに宿泊する資格がありますが、バイス・プレジデント以下の管理レベルの従業員はその資格がありません。同様に、エグゼクティブ・バイス・プレジデント以上の管理レベルの従業員はファースト・クラスに搭乗する資格がありますが、バイス・プレジデント以下の管理レベルの従業員はビジネス・クラスの資格があるのみです。

  • それぞれの国または地域の言語で表示される予約サイトを会社が必要としている。

トラベル・パートナによって、そのシステムで予約サイト・インスタンスが構成され、それらのインスタンスを表すサイト名、および管理アクセス用のサインイン資格証明が提供されます。

出張ポリシーおよびポリシー違反の構成

トラベル・パートナのシステムで出張ポリシーを作成して、会社の出張ポリシーを適用します。設定した予約サイトごとに、出張ポリシーおよびポリシー違反を構成する必要があります。Expensesでトラベル・パートナを設定すると、出張ポリシー違反および理由が旅程とともにExpensesにダウンロードされます。

従業員のアクセス方法の決定

従業員が予約サイトにアクセスおよびサインインする方法を会社で決定する必要があります。会社は、次の2つのうちのいずれかの方法でサインイン・アクセスを有効にできます。

  • シングル・サインオン(SSO)

  • トラベル・パートナによる認証

すべてのユーザー・アカウントおよびパスワードを一元的に管理するシステム(アイデンティティ・プロバイダとのフェデレーテッド認証と呼ばれる)がすでに会社にあり、すべてのシステムへのサインインがこの中央システムを介してルーティングされる場合、予約サイトへのアクセスにも同じ機能を使用できます。SSOを有効にすると、従業員パスワードはトラベル・パートナのシステムに格納されません。すべての予約サイトまたは特定の予約サイトについてSSOを有効にできます。

注意:

SSOが有効になっている予約サイトで従業員を設定する場合は、予約サイトの従業員ユーザー名をIdPの対応するユーザー名と一致させることをお薦めします。たとえば、従業員ユーザー名がEメール識別子である場合、予約サイトのユーザー名もEメール識別子にすることをお薦めします。

サインイン・アクセスを有効にする別の方法は、トラベル・パートナによる認証です。このシナリオでは、トラベル・パートナのシステムで従業員をそのユーザー名およびパスワードとともに予約サイトと関連付けます。従業員が予約サイトにアクセスするときに、ユーザー名とパスワードを入力すると、そのサインイン資格証明が予約サイトによって検証されます。このアクセス方法では、ユーザー名が他のシステムのものと一致している必要はありません。

従業員の設定

トラベル・パートナによってそのシステムで予約サイト・インスタンスが構成されたら、トラベル・パートナのシステムで従業員とそのサインイン資格証明を設定できます。出張ポリシーがジョブ・ロールや他の基準によって異なる場合は、トラベル・パートナのシステムで従業員ごとに関連情報を設定する必要があります。この情報によって、関連する予約サイトへの従業員のアクセス権も決まります。