旅程検証ルールの設定方法
正確な出張データに依拠して、出張に関する会社全体の意思決定を戦略的に行うことがきわめて重要です。
出張データの精度を高めるとともに、承認者および監査者がポリシー違反を把握できるようにするために、インポート時または検証プロセスの実行時に旅程に対して機能する検証を有効にできます。
旅程検証ルールは、「旅程検証ルールの管理」ページで設定できます。これらを適用するには、トラベル・パートナまたは特定の予約サイトに割り当てます。
アプリケーションでは、次の2つのタイプの旅程検証ルールが実行されます:
-
常に行われる検証
-
有効にできる検証
GetThereについて常に行われる検証
「旅程のインポート」プロセスには、次のものを識別する検証があります:
-
拒否対象の無効な旅程
-
クリティカルな検証エラーがある旅程
拒否され、インポートされなかった旅程は、「出張管理」作業領域の「旅程インポート要求」表に表示されているプロセスについて「旅程インポート失敗」件数のゼロ以外の値をクリックすると「旅程インポート失敗」ダイアログ・ボックスに表示されます。これらには、次のいずれかのエラーがある可能性があります:
-
旅程ステータスがNullです。
-
旅程の最終変更タイム・スタンプがnullであるか、無効な書式です。
-
旅程に無効な予約があり、予約確認番号がnullです。
-
旅程の詳細をインポートしようとしているときに予期しないエラーが発生しました。
常に行われる検証には、設定は必要ありません。
インポートに失敗した旅程については出張が作成されず、修正のためにそれらの詳細にアクセスすることはできません。「旅程のインポート」プロセスでは、プロセス・パラメータで指定された、失敗した最初のインポートからの経過日数の間、失敗した旅程の再インポートが試行されます。
サードパーティ・トラベル・パートナについて常に行われる検証
出張管理者は、RESTサービスを使用して、指定した書式でサードパーティ出張サイトから旅程データを転記します。次の状況では、旅程は作成または更新されません:
-
必須フィールドが使用できない。
-
フィールドが、定義されたデータ書式または長さ制限に準拠していない。
-
フィールドが検証ルールに準拠していない。
-
重複レコードが転記された。
次のデータ・フィールドのいずれかの値が欠落しているか無効である場合、旅程は拒否されます:
セグメント |
データ・フィールド |
---|---|
旅程 |
トラベル・パートナ出張番号 |
旅程 |
旅程レコード・ロケータ |
旅程 |
トラベル・パートナ名 |
旅程 |
予約サイト名 |
旅程 |
名 |
旅程 |
姓 |
旅程 |
予約日時 |
旅程 |
ステータス・コード |
予約 |
予約タイプ |
予約 |
通貨コード |
予約 |
金額 |
航空 |
項目確認番号 |
航空 |
出発日時 |
航空 |
出発地 |
航空 |
到着日時 |
航空 |
到着地 |
鉄道 |
項目確認番号 |
鉄道 |
出発場所名 |
鉄道 |
出発日時 |
鉄道 |
出発地 |
鉄道 |
到着場所名 |
鉄道 |
到着日時 |
鉄道 |
到着地 |
ホテル |
確認番号 |
ホテル |
開始日時 |
ホテル |
終了日時 |
ホテル |
基準レート |
ホテル |
宿泊地 |
車両レンタル |
確認番号 |
車両レンタル |
開始日時 |
車両レンタル |
終了日時 |
車両レンタル |
ピックアップ地 |
車両レンタル |
返却地 |
次の検証が失敗すると、旅程は拒否され、エラーが表示されます:
セグメント |
データ・フィールド |
検証 |
---|---|---|
旅程 |
トラベル・パートナ名 |
旅程内のトラベル・パートナ名は、割り当てられたトラベル・パートナ名と一致する必要があります。 |
旅程 |
予約サイト名 |
旅程内の予約サイト名は、トラベル・パートナ用に作成された予約サイト名と一致する必要があります。 |
旅程 |
名 |
旅程に記載されている名と姓は、既存の従業員レコードに存在する必要があります。 |
旅程 |
姓 |
旅程に記載されている名と姓は、既存の従業員レコードに存在する必要があります。 |
旅程 |
従業員番号 |
従業員番号、名および姓は、既存の従業員レコードと一致する必要があります。 |
旅程 |
予約日時 |
転記または修正された旅程の新規レコードのタイム・スタンプは、同じ旅程の既存のレコードの予約日時より後である必要があります |
旅程 |
ステータス・コード |
旅程内のステータス・コードは、アクティブ、チケット発券済、取消済など、予想されるステータス・コードと一致する必要があります。 |
予約 |
予約タイプ |
旅程内の予約タイプは、航空、鉄道、ホテル、車両レンタルなど、予想される予約タイプと一致する必要があります。 |
一部の検証は、RESTサービスを使用して旅程が転記または修正されたときに実行されます。エラーが見つかった場合、旅程は拒否され、エラーを解決して旅程を再度送信する必要があります。
正常に転記された旅程については、検証プロセスを実行して、対応する出張を作成する必要があります。検証エラーが見つかった場合は、「出張管理」作業領域からそれらを修正し、検証を再度実行する必要があります。
検証エラーの修正
次のようなクリティカルな検証エラーがある旅程は、出張を作成する前に修正する必要があります:
-
従業員番号の欠落または不一致
-
1つ以上の予約における、金額や通貨などの価格設定情報の欠落
-
旅程の検証中の予期しないエラー
「旅程インポート結果のレビュー」ページで、クリティカルな検証エラーがある旅程を修正できます。「出張管理」作業領域の「旅程インポート要求」表に表示されているプロセスについてクリティカルな検証エラー件数のゼロ以外の値をクリックすると、「旅程インポート結果のレビュー」ページにナビゲートして、それらのエラーが表示されます。
クリティカルな検証エラーがある旅程についても、出張は作成されません。GetThereで作成された旅程については、「旅程のインポート」プロセスによって、検証エラーがあるすべての旅程の再検証が続行され、クリティカルな検証エラーが修正されたら、旅程について出張が作成されます。同様に、サードパーティ・トラベル・パートナによって作成された旅程の検証により、必ず、クリティカルな検証エラーが修正された後にのみ出張が作成されるようになります。
有効にできる検証
出張データの品質を向上させるために、旅程検証のセットを有効にできます。次の旅程検証では、説明に従って追加設定を行う必要があります:
-
ポリシー違反の検証
-
業者の検証
-
場所の検証
-
航空チケット区分の検証
-
通貨コードおよび金額
-
日時
-
フライトまたは列車番号
次の表は、有効にできる検証とそれに関連する設定ステップについて説明しています。
検証 |
検証を有効にするステップ |
---|---|
ポリシー違反の検証 |
「旅程のインポート」プロセスおよび検証プロセスでは、「旅程検証ルールの管理」ページでポリシー違反検証ルールに割り当てられた、ソース参照として指定されたポリシー違反に対して、トラベル・パートナによって提供されるポリシー違反が検証されます。
ベース言語以外の言語でポリシー違反を受信する場合は、異なる言語でのポリシー違反をサポートするよう、参照コード内容について言語固有のテキストを設定する必要があります。 たとえば、米国とフランスの2つの予約サイトが会社にあるとします。トラベル・パートナは、地域の言語であるフランス語でポリシー違反を提供します。最低運賃が選択されていない場合、両方の予約サイトでポリシー違反が適用されます。従業員が最低運賃を選択しない場合は、時間に制約があるため直行便が必要だったという事由を使用してポリシー違反の理由を示す必要があります。 旅程インポートまたは旅程検証中に両方のサイトからの旅程に対して最低運賃ポリシーを適用するには、ポリシー違反メッセージを英語とフランス語で内容として定義する必要があります。 アプリケーションに存在しないポリシー違反がある旅程は、「不一致の値」検証エラーとしてタグ付けされます。 |
業者の検証 |
アプリケーションに存在しない業者が含まれている旅程は、「不一致の値」検証エラーとしてタグ付けされます。 |
場所の検証 |
場所の検証は、Oracle Fusion Applications Trading Community Architectureに一元的に格納されている地理データに対して実行されます。
アプリケーションに存在しない場所が含まれている旅程は、「不一致の値」検証エラーとしてタグ付けされます。 |
航空チケット区分の検証 |
航空チケット区分の検証は、EXM_TICKET_CLASS参照タイプに対して実行されます。この参照タイプを構成して、新しい航空チケット区分を追加できます。
アプリケーションに存在しない航空チケット区分が含まれている旅程は、「不一致の値」検証エラーとしてタグ付けされます。 |
通貨コードおよび金額 |
設定は必要ありません。Oracle Fusion General Ledgerの通貨が検証に使用されます。 |
日時 |
設定は必要ありません。これは標準の日時検証です。 |
フライトまたは列車番号 |
設定は必要ありません。アプリケーションによって、フライトまたは列車番号が存在することが検証されます。 |
有効にできる検証に失敗した旅程については、アプリケーションによって出張が作成されます。出張管理者は、必要に応じて検証エラーと旅程を修正できます。