事前申請：
TMC 統合
設定ガイド
最終更新日: 2016 年 10 月 20 日
以下の Concur ソリューションに適用されます。
Expense
Professional/Premium edition
Integrated with Professional/Premium Travel Stand-alone
Standard edition
Integrated with Standard Travel Stand-alone
Concurforce
Travel
Professional/Premium edition
Integrated with Professional/Premium Expense Integrated with Professional/Premium Request Stand-alone
Standard edition
Integrated with Standard Expense Stand-alone
Invoice Management
Professional/Premium edition
Integrated with Professional/Premium Expense Stand-alone
Standard edition
Integrated with Standard Expense Stand-alone
S Authorization Request (formerly Travel Request) S Professional/Premium edition
Integrated with Professional/Premium Expense S Integrated with Professional/Premium Travel S Stand-alone
Standard edition
Integrated with Standard Expense Stand-alone
目次
セクション
1:対象...1
セクション
2:アクセス許可...1
セクション
3:申請
/購買申請
/ 事前申請...1セクション
4:事前申請の機能の概要...1
セクション
5:事前申請の構成...2
セクション
6: TMC 統合の概要...2事前申請の重要文書...3
出張予約の文書...3
申請の処理フロー...4
セクション
7:出張予約と事前申請の機能連動...10
機能リスト...10
事前申請と出張予約が統合済の場合の必須構成...12
事前申請の統合における出張ルール アクション...12
ゲスト出張者機能...16
セクション
8: PNR 最終処理...17セクション
9:オンラインの利用促進...18
セクション
10:出張および承認の有効期限...19
出張の有効期限および承認期限...19
セクション
11:オフライン
PNR の要件...20シナリオ構成...20
必須行...21
オプション行...25
改訂履歴
日付 注意事項/コメント/変更内容
2016 年 10 月 20 日 「アクセス許可」セクションおよびガイド コンテンツを新様式に更新しました。内容の 変更はありません。
2016 年 5 月 20 日 「オフライン PNR の要件」セクションに「シナリオ構成」セクションを追加しました。
2016 年 5 月 16 日 「事前申請でオフライン予約された申請（オフライン PNR 取得を使用）」セクションを 更新し、「アクセス許可」セクションおよびガイド コンテンツを新様式に更新しまし た。
2016 年 4 月 28 日 「ポリシー準拠」の情報を修正しました。
2016 年 4 月 1 日 「事前申請と出張予約が統合済の場合の必須構成」セクションを追加しました。
2016 年 3 月 18 日 「事前申請で作成され、オンライン予約のため出張予約へ送られた申請（承認から予約 への処理フロー）」を更新しました。
設定ガイド 事前申請： TMC 統合 i
日付 注意事項/コメント/変更内容
2016 年 2 月 26 日 「事前申請でオフライン予約された申請（オフライン PNR 取得を使用）」セクションを 追加しました。
2015 年 11 月 3 日 出張予約の「機能リスト」セクションを更新し、承認者のメールの最低運賃がサポート された旨の注釈を記載しました。
2015 年 8 月 14 日 「出張予約の文書」セクションを更新しました。
2015 年 7 月 10 日 「出張予約の文書」セクションおよび「ゲスト出張者機能」セクションを追加し、「事 前申請の重要文書」セクションを更新しました。
2015 年 4 月 30 日 異なる処理フローについてのキャンセル詳細を更新しました。
2015 年 4 月 23 日 「TMC 統合の概要」、「機能リスト」、および「ポリシー準拠」セクションを更新しま した。
2015 年 3 月 13 日 「事前申請の重要文書」セクションを更新し、現在のユーザー インターフェイスから参 照を削除しました。
2015 年 1 月 16 日 事前申請の機能リストが付随する出張予約の [機能相互作用] に [運賃の再検証] を追 加しました。
2014 年 10 月 21 日 事前申請の統合に対して、新しい出張ルール アクションについての情報を追加しまし た。
2014 年 10 月 17 日 初版発行
TMC 統合
セクション 1: 対象
本ガイドは、出張管理会社（TMC）と事前申請の統合をサポートするために必要な情報が記載さ れています。主な対象は出張管理会社における旅行会社です。
セクション 2: アクセス許可
ユーザーがこの機能へのアクセス許可を持っているかどうかは場合によります。たとえば、特定 のグループに対してのみアクセス権がある、または読取専用で作成や編集はできないなど、限定 的なアクセス権を持っている場合があります。
管理者はこの機能を使用する必要がありますので、適切なアクセス権がない場合は、社内の Con cur 管理者に連絡してください。
さらに、このガイドに記載されている作業は Concur にのみ許可されているものもあります。必 要に応じて Concur クライアント サポートにご依頼ください。
セクション 3: 申請 / 購買申請 / 事前申請
事前申請サービス（旧称 購買申請）は、Request または Concur Request とも呼ばれます。
セクション 4: 事前申請の機能の概要
ユーザーへの表示、承認者への表示、ワークフロー設定、基本的な設定など、申請の全般情報に ついては、設定ガイド「事前申請 : Overview」をご参照ください。
セクション 5: 事前申請の構成
事前申請に関する実装をすべて行った場合でも、全機能は利用可能な状態になりません。TMC 統 合は事前申請が出張予約と統合済の場合に利用可能です。
実装 事前申請の利用
スタンドアロン いいえ
経費精算と統合（出張予約なし） いいえ
出張予約と統合（経費精算なし） オプションで利用可能
経費精算および出張予約と統合
注意： この構成は出張予約ではなく、経費精算および事前申請のワ ークフローで使用します。
オプションで利用可能
設定ガイド 事前申請： TMC 統合 1
セクション 6: TMC 統合の概要
事前申請は申請のライフサイクルの様々なポイントにおいて、TMC 統合を取り入れることができ ます。構成により、TMC は以下が実行できます。
提出済の申請を基にした複数の見込み旅程の作成（[代理店の提案] 機能を使用）。
のちに事前申請にインポートする旅程の作成（[オフライン PNR の取得] 機能を使 用）。申請ワークフローの完了後、事前申請が該当の出張を TMC のチケット販売の順番
待ちに送信。
承認済の申請に基づいて旅程を作成および発券。
出張予約で予約して PNR で既に確認済、かつ申請ワークフローで承認済のチケット を発券。
NOTE: [オフライン PNR の取得] および [代理店の提案] は Egencia と統合していません。
事前申請の重要文書
事前申請は広く構成可能で、多くのオプション機能を備えています。これらの機能および処理フ ローについては下記のガイドに詳細を記載しています。TMC はこれらのガイドを参考にして事前 申請の構成可能な機能について理解を深めてください。
機能 ガイド
事前申請の処理フロー、エンド ユー
ザーの操作 設定ガイド「事前申請： Overview」
旅行会社の構成 設定ガイド「事前申請： 旅行会社のオフィス」
代理店の提案 設定ガイド「事前申請： Agency Proposals」
オフライン PNR の取得 設定ガイド「事前申請： 旅行会社のオフィス」
予約の切り替え 設定ガイド 「事前申請： Booking Switch」
TMC へのメール通知 設定ガイド「事前申請： ワークフロー - 概要」、設定ガイド
「事前申請： Policies and Groups」、設定ガイド「事前申請：
Printed Reports Configuration」
注意： 旅程にポリシー違反が含まれている場合、メール通知は 出張予約と統合済のお客様に対して旅程の詳細を含めることがで きます。詳細は、事前申請の構成管理者により印刷用レポート テンプレートに追加されます。
詳しくは、設定ガイド「事前申請： Printed Reports Conf iguration」 をお読みください。鉄道の場所構成 設定ガイド「事前申請： Policies and Groups」
出張予約の文書
出張予約の文書は以下の場所からご参照ください。このガイドおよび TSG は、パッシブ セグメ ントの正しいフォーマット、ポリシー違反や LLF 構成、およびその他の出張予約の機能などの、
出張予約と事前申請の様々な統合構成を完了する際にご利用いただけます。
出張製品ガイド：
http://www.concurtraining.com/customers/tech_pubs/TravelDocs/available.htm 出張サービス ガイド：
http://www.concurtraining.com/customers/tech_pubs/TravelDocs/TSGs/_TSGs_client.htm
申請の処理フロー
処理フローでは、以下に注意してください。
オンラインとは、出張予約内での予約を指しています（自己予約）。
オフラインとは、出張予約外での予約を指しています（旅行会社による予約）。
NOTE: 旅行会社の構成では、各申請グループへのメール通知において、ひとつまたは複数のメ ール アドレスを指定します。TMC は通知を監視するメール アドレスを構成してくださ い。
出張予約でオンライン予約済、かつ事前申請へ送信済の申請（予約から承認への処理フロ ー）
1. 出張者は [出張検索] パネルで出張の説明を入力し、[検索] をクリックします。
2. （[予約の切り替え] が有効の場合）出張予約出張予約は [予約の切り替え] 申請を事前 申請に送り、事前申請は以下のように返します。
自己予約 ＝ はい オンラインで予約された出張の場合。出張者は出張ウィザードに
リダイレクトされます。
自己予約 ＝ いいえ オフラインで予約された出張の場合。申請は出張申請の要請の
ため作成される申請 ID を含みます。出張者は、旅程情報（ユーザーの手入力によ るセグメント）が既に入力済の新規の申請にリダイレクトされます。この申請は、本ガイドの「事前申請でオフラインで予約された申請（オフライン PNR 取得の使用 なし）」の項で後述されるとおりに処理を続けます。
3. 出張者は出張予約で旅程をまとめます。
4. 出張予約は選択された最初のサービスの PNR を作成し、その他の予約をそれに追加しま す。
5. 出張全体を確認する際、出張予約は申請が必要かどうか判断します。これは [出張構成]
> [Request 統合を有効化] で設定可能で、以下のオプションをサポートしています。
申請を常に作成
設定ガイド 事前申請： TMC 統合 3
出張ルールに基づき申請を作成
6. 申請が必須の場合、PNR 保留中に申請が作成され 旅程が入力されます。出張はその後、
「申請承認待ち」のステータスになります。
7. 申請は承認ワークフローに従って進みます。
8.
ワークフローが正しく完了すると、事前申請は出張予約に承認申請を送り、出張は TMC
のチケット販売の順番待ちに並びます。9. 旅行会社がチケットを発行します。
NOTE: 申請が完全に承認されると、実際の旅程が申請と異なる場合でも、それ以降の更 新はありません。
10. 申請が出張者によりキャンセルされた場合、事前申請はキャンセルの旨を出張予約に送 ります。
承認前： キャンセルの実行を制御することはありません。出張は期限切れになりま す（出張予約で構成必須）。
承認後： PNR は Concur によりキャンセルの順番待ちに置かれます。
承認後、かつ出張予約でキャンセルが失敗、かつ旅行会社の事後承認キャンセル通
知がアクティブの場合： TMC へメール通知が送られます。
事前申請で作成され、オンライン予約のため出張予約へ送られた申請（承認から予約への処 理フロー）
1. 出張者は [申請] メニューから申請を作成します。
2. 出張者は申請を完了し、セグメントに旅程の詳細を手入力します。
3. 申請は承認ワークフローに従って進みます。
4. 最終承認後、申請は [予約保留中] のワークフロー ステップに入ります。
5. ユーザーは実際の旅程を予約するため出張予約にリダイレクトされます。
NOTE: 会社によっては、オプションで [出張予約] タブへのユーザー アクセスを削除 している場合があります。これは、出張予約時にユーザーに申請の [予約] / [出張予約で予約] リンクやボタンをクリックさせる意図があります。詳しい情 報は、設定ガイド「事前申請： ワークフロー - 概要」をお読みください。
6. 予約完了後、出張予約は該当の出張を TMC のチケット販売の順番待ちに送信します。
7. 旅行会社がチケットを発行します。
NOTE: 処理フローを使用しているお客様は、管理者が事前申請を構成して、申請が「承 認済 - 予約保留中」のワークフロー ステップに至り次第、出張予約からの申請
金額の更新を許可することができます。詳しくは、設定ガイド「事前設定 : サ
イト設定」をご参照ください。8. 申請が出張者によりキャンセルされた場合、事前申請はキャンセルの旨を出張予約に送 ります。
承認前： キャンセルの実行を制御することはありません。出張は期限切れになりま す（出張予約で構成必須）。
承認後： PNR は Concur によりキャンセルの順番待ちに置かれます。
承認後、かつ出張予約でキャンセルが失敗、かつ旅行会社の事後承認キャンセル通
知がアクティブの場合： TMC へメール通知が送られます。
事前申請でオフラインで予約された申請（オフライン PNR 取得の使用なし）
1. 予約の切り替え（先のセクションに記載のとおり）から作成、またはユーザーが [申請]
メニューから申請を作成、のいずれかにより申請は作成されます。
2. 出張者は申請を完了し、セグメントに旅程の詳細を手入力します。
3. （構成オプション）オプションの事前予約のため旅行会社にメールが送られます（少な くともひとつのセグメントが旅行会社のアクションを必須とする場合）。
4. （構成オプション）旅行会社は事前申請にログインし、出張の詳細を含む出張申請を更 新できます。
5. 申請は承認ワークフローに従って進みます。
6. 最後の承認時に、出張の予約およびチケットの発行のためのメール通知が旅行会社に送 られます（少なくともひとつのセグメントが旅行会社のアクションを必須とする場合）。
NOTE: 事前申請に自己予約セグメントのみが含まれる場合、旅行会社には通知されませ ん。
NOTE: 申請が完全に承認されると、実際の旅程が申請と異なる場合でも、それ以降の更 新はありません。
7. （構成オプション）申請がキャンセルされた場合（承認前または後に）、メール通知が TMC に送られます。
事前申請でオフライン予約された申請（オフライン PNR 取得を使用）
ワークフローの構成についての詳しい情報は、設定ガイド「事前申請 : ワーク フロー - 概要」をお読みください。
1. ユーザーは申請を作成し提出します。
設定ガイド 事前申請： TMC 統合 5
2. メール通知がが TMC に送られます。
3. TMC は PNR を作成し、それをオフライン承認順番待ちに出します。
4. 旅程は申請 ID とともに保存されます。
5. 申請は通知されます。Concur は、PNR で指定された申請 ID を会社および Cocnur のユ ーザーと比較して PNR を検証します。会社またはユーザーのどちらも申請 ID と一致し ない場合、PNR は無効と認識され、[オフライン承認エラー順番待ち] に送られます（構 成されている場合）。
システムは以下の 2 つのデータを制御します。
申請 ID
ユーザー識別のための CUUID
NOTE: オフライン承認待ちから PNR を削除すると、エラーの分析は提供されません。
6. 事前申請は出張（この時点で「自己予約」の出張と認識されている）をアップロードし、
次のワークフロー ステップへ進みます。
7. 申請は承認ワークフローに従って進みます。
8.
ワークフローが正しく完了すると、事前申請は出張予約に承認申請を送り、出張は TMC
のチケット販売の順番待ちに並びます。NOTE:
通知は出張予約が対応するため、事前申請は承認後に TMC にメール通知を送り
ません。9. 旅行会社がチケットを発行します。
NOTE: 申請が完全に承認されると、実際の旅程が申請と異なる場合でも、それ以降の更 新はありません。
10. 申請が出張者によりキャンセルされた場合、事前申請はキャンセルの旨を出張予約に送 ります。
承認前： キャンセルの実行を制御することはありません。出張は期限切れになりま す（出張予約で構成必須）。
承認後： PNR は Concur によりキャンセルの順番待ちに置かれます。
承認後、かつ出張予約でキャンセルが失敗、かつ旅行会社の事後承認キャンセル通
知がアクティブの場合： TMC へメール通知が送られます。
事前申請でオフライン予約された申請（代理店の提案を使用）
1. ユーザーが事前申請で出張申請を作成します。
2. ユーザーはワークフローで出張申請を提出します（最初のステップは TMC の旅行会社で ある必要があります）。
3. 事前申請は出張情報を TMC へ送ります（AEBT または CWT の特定の機能）。または TMC は事前申請の詳細を使用します（Concur プラットフォームの一般機能）。
4. TMC が 1～3 件の見込み旅程の提案を作成します（PNR で作成する場合もあればそうで ない場合もあります）。
5. TMC は事前申請に提案を出します。
6. 事前申請は比較ポップアップを介してユーザーへ発表します。
7. ユーザーは提案をひとつ選択します。
8. 事前申請は申請が完全に承認されるまで承認ワークフローを進みます。
9. 事前申請は承認通知を TMC に送ります（AEBT または CWT の特定の機能）。または TMC は Web サービスを使用して提案ステータスを確認します（Concur プラットフォームの
一般機能）。
10. TMC は出張を発券します。
NOTE: 申請が完全に承認されると、実際の旅程が申請と異なる場合でも、それ以降の更 新はありません。
11. 申請が出張者によりキャンセルされた場合、事前申請はキャンセルの旨を出張予約に送 ります。
承認前： キャンセルの実行を制御することはありません。出張は期限切れになりま す（出張予約で構成必須）。
承認後： PNR は Concur によりキャンセルの順番待ちに置かれます。
承認後、かつ出張予約でキャンセルが失敗、かつ旅行会社の事後承認キャンセル通
知がアクティブの場合： TMC へメール通知が送られます。
その他の出張関連のセグメント
TMC は、ユーザーの目的に沿ってその他の出張関連の項目（査証、旅行保険、または海路）を予 約する場合があります。これらは通常、事前申請のその他のセグメント タイプで取扱われます。
これらのセグメントの更新は、オフライン PNR や代理店の提案機能ではサポートされていませ ん。現在は、空路、鉄道、レンタカー、およびホテルのみがサポートされています。これらのセ グメントは旅行会社が予約するためメールに含まれる場合があります。ただし、旅行会社がオフ ライン PNR や代理店の提案処理を完了した場合、このセグメントは事前申請で更新されなくな ります。
このセグメントは [申請ポリシー] で構成します。
詳しい情報は、設定ガイド「事前申請： Policies and Groups」をご参照くださ い。設定ガイド 事前申請： TMC 統合 7
セクション 7: 出張予約と事前申請の機能連動
機能リスト
事前申請と出張予約が統合されている場合、出張予約の一部の機能が事前申請に影響する場合が あります。影響を受ける機能は下記の通りです。
出張予約の機能 事前申請への影響
モバイルによる承認 サポートされています。
メールによる承認 サポートされていません。
モバイルによる予約 予約から承認処理フローを使用の場合、一部サポートされていま す。
運賃の再検証 事前申請と統合済の場合、サポートされていません。
ゲスト出張者 事前申請でサポートされていません。出張予約から事前申請への 処理フローで使用することにより、事前申請と統合済の出張予約 にて使用可能です。
詳細については、本ガイドのセクション「ゲスト出張者」をご参 照ください。
パッシブ承認 サポートされていません。申請ワークフローの期限切れアクショ ンで代替オプションが利用可能です。
承認者メールの最低運賃 サポートされています。
複数乗客の予約 サポートされていません。
モバイル - 事前申請の統合 事前申請の統合を有効化すると [申請を常に作成] - モバイルに [予約] アイコンは表示されません。
[申請を常に作成] および [予約の切り替え] - モバ イルに [予約] アイコンは表示されません。
[出張予約のルールに基づき申請を作成] - モバイル に [予約] アイコンが使用を限定された状態で表示されま す。
[出張予約のルールに基づき申請を作成] および [予 約の切り替え] - モバイルに [予約] アイコンが使用を限定 された状態で表示されます。
マネージャーが旅程で出張を承認す ると、出張予約にその他の選択肢が 表示されます。
これは事前申請では異なっており、承認者は [申請を表示] オプ ションをクリックし、[セグメント] フォームからその他の選択 肢を確認する必要があります。
事前申請と出張予約が統合済の場合の必須構成
[Request 統合を有効化] 設定（出張構成ページの [ウィザード オプション] セクション内）を
選択済の場合、[承認前に最終処理を強制] 設定（出張構成ページの [PNR 最終処理構成] セク
事前申請の統合における出張ルール アクション
事前申請で使用する出張ルール アクションは以下の 2 つです。
事前承認が必須＆通知
事前承認が必須＆ログ
これらのルール アクションは、事前申請と出張予約が統合済で、出張予約で構成されている場 合にご使用いただけます。また、出張予約の管理者は、2 つのそれぞれの処理に対し同じルール クラスを使用することができます。
1. 承認から予約： 事前申請で開始し、出張予約で予約 2. 予約から承認： 出張予約で開始し、申請を作成
重要： この 2 つのオプションは、出張予約の事前申請機能とは無関係です。
背景
統合の構成で、様々な方法で事前申請と出張予約間で情報共有が行われるよう設定することがで きます。次のうちいずれか、またはすべての処理をを使用して構成可能です。
シナリオ 1 - 事前申請で開始：
事前申請にて： ユーザーが申請を作成して提出します。
事前申請にて： 申請は承認ワークフローに従って進みます。
出張予約にて： ユーザーは出張予約にリダイレクトされ、出張ウィザードでセグメ ントを予約します。
シナリオ 2 - 出張予約で開始（出張ルールに関わらず、申請が常に作成されるよう 設定されている場合）：
出張予約にて： ユーザーが出張ウィザードで出張セグメントを予約します。
事前申請にて： セグメント情報が出張予約から 事前申請に送られ、申請に自動入
力されます。ユーザーは申請をチェックして情報を追加し、提出します。
事前申請にて： 申請は承認ワークフローに従って進みます。
シナリオ 3: 出張予約で開始（承認が必須というルールに違反した場合のみ申請が 作成されるよう設定されている場合）：
出張予約にて： ユーザーが出張ウィザードで出張セグメントを予約します。
承認が必須の場合は、シナリオ 2 をお読みください。
承認が必須ではない場合、出張はそのまま確定します。
シナリオ 4 - オフライン/オンライン ポリシーを強制:
このプロセスでは、どこから申請を開始しても構いません。ユーザーが（事前申請 で）申請を提出する際、出張予約で完了すべき予約の箇所がないかどうか、オフラ イン/オンライン設定が判断します。ある場合は、ユーザーは出張予約リダイレクト されます。
出張予約にて： ユーザーが出張ウィザードで出張セグメントを予約します。
設定ガイド 事前申請： TMC 統合 9
事前申請にて： セグメント情報が出張予約から 事前申請に送られ、申請に自動入
力されます。ユーザーは申請を確認し、再提出します。
事前申請にて： 申請は承認ワークフローに従って進みます。
新ルール アクション
この新規ルール アクションは、関連する出張ルールに違反していないかどうかを判断します。
NOTE: 次の例では、事前申請が出張予約と統合済のため、出張予約で承認がないことに注意し てください。承認が必須の場合は、必ず事前申請で完了します。
シナリオ 1 は事前申請で開始しますが、これは出張ウィザードにリダイレクトされる時点で申 請がすでに承認されているためです。
ユーザーがフライトやレンタカーを選択すると、[事前承認が必須＆通知] または [事前 承認が必須＆ログ] のルールに違反します。
次に下記の操作をします。
[事前承認が必須&通知] ルールが [マネージャーに通知] と同様に機能します。[事前承 認が必須＆ログ] ルールは [レポートのログ] と同様に機能します。
– および –
[選択/予約] ボタンが黄色になります。
– および -
ユーザーは違反理由を選択する必要があります。これは旅程に記録されます。
[事前承認が必須 & 通知] の場合、既定の承認者が出張予約に存在していればそのユー ザーにメールで通知します。アクションは不要ですが、出張は確定します。
出張管理者が [マネージャーへの通知] または [レポートのログ] のレポートを実行す ると、これらの取引が表示されます。
シナリオ 2、3、4（つまりユーザーが出張ウィザードを使用する時に申請が承認されていない）
の場合:
ユーザーがフライトやレンタカーを選択すると、[事前承認が必須＆通知] または [事前 承認が必須＆ログ] のルールに違反します。
次に下記の操作をします。
ルールは [承認が必須] と同じように機能します:
– かつ –
[選択/予約] ボタンが赤になります。
– かつ -
ユーザーは違反理由を選択する必要があります。これは申請承認者に返されます。
出張管理者が [承認が必須] の違反レポートを実行すると、これらの取引が表示されま す。
お客様 / ユーザー / TMC への利点
事前申請が出張予約と統合済の場合は、上記の予約プロセスのいずれか、またはすべてを使用す ることができます。これらのルール アクションはどのシナリオにも使用できます。シナリオご とに異なるアクションを使用する必要はありません。
一般的な使用例
社内にユーザー グループがいくつかあります。一部のグループは、出張計画を立てる前に事前 承認を得る必要があります。その他のグループは必須ではありません。それ以外に関しては、す
べてのグループで条件は同じです。同じルール クラスで同じ設定を使用できます。
新しい２つのルール アクションを使うと、これらのグループは同じルール クラスで事前承認が 必須かどうかによって異なる結果を得ることができます。出張管理者がそれぞれのグループに対 してルール クラスを作成する必要はありません。
管理者への表示
出張管理者には、[出張管理] ページの [出張ポリシー] タブに新しいルールアクションが表示 されます:
詳しい情報は、ユーザー ガイド「出張予約： 法人管理」 をご参照ください。ゲスト出張者機能
出張予約と事前申請を統合済のお客様は、出張予約でゲスト出張者機能を使用できます。この機 能は、オンラインの出張予約から事前申請への処理フローを使用、またはオフラインの事前申請 から出張予約への処理フローを使用する場合に限りサポートされます。
設定ガイド 事前申請： TMC 統合 11
この機能は事前申請と次のように連動します。
オンライン： 出張予約から事前申請への処理フロー
出張手配者が出張予約でゲスト出張者の予約を完了すると、その情報が事前申請に 送られます。
関連する申請が手配者の名前で作成されますが、旅程はゲスト出張者の名前で予約
されます。ゲスト出張者のフィールド情報は予約処理中にセグメントに入力されます。 事前申請は承認のためワークフローを適切に通過し、TMC のチケット販売に送られ ます。申請は手配者のポリシーおよびワークフローを使用します。
オフライン： 事前申請から出張予約への処理フロー
事前申請の構成管理者は、ゲスト ユーザーの名前やその他の必須フィールド取得の ため、[申請ヘッダー] フォームにカスタム フィールドを追加する必要があります。
経費支給者は、申請を作成し、ゲスト ユーザーの名前を新規カスタム フィールド
に入力して通常通りセグメントを作成します。 承認後、TMC にメールが送られます。メール通知はセグメント情報、ゲストのカス タム フィールド情報、およびその他の必須フィールドを含んでいます。
詳しい情報は、設定ガイド「事前申請： Printed Reports Configuration」、お よび設定ガイド「事前申請： ワークフロー - 概要」をご参照ください。 TMC はゲスト ユーザーの名前で PNR を予約し、申請 ID および PNR 内の経費支給 者の CLIQCID を使用します。
オフライン承認順番待ちに並ぶ場合、セグメント詳細は事前申請で入力され、承認 を通ってチケット販売に送られます。
オンライン： 事前申請から出張予約への処理フロー
ゲスト出張者機能は事前申請ではサポートされていないため、この処理フローでは使用できませ ん。
セクション 8: PNR 最終処理
特定の申請のフィールドは PNR 最終処理で使用可能です。これらのフィールドは [Travel シス テム管理] 内の [最終処理テンプレート エディター] で追加できます。
申請フィールドを追加するには：1. [管理] ＞ [Travel システム管理] を順にクリックします。
2.
左側メニューの [プロファイルおよび最終処理] セクションにある [最終処理テンプレ
ート エディター] をクリックします。3. 目的の会社を選択します。
4. 目的の最終処理テンプレートに対して [編集] をクリックします。
5. [行を追加] をクリックまたは既存の行を編集します。
6. [ノード] を選択します。利用可能な申請フィールドはこちらにあります： /PNRFinish
Data/CteTravelRequest/
フィールド 説明
TravelRequestId 出張申請の一意の識別子
目的 申請の [目的] フィールド
カスタム 1 ～ カスタム 20 申請のカスタム フィールド ラベル カスタム 1 コード ～ カスタム 20 コー
ド 申請のカスタム フィールド コード
セクション 9: オンラインの利用促進
事前申請にはオンラインの利用（出張予約での予約）を促進する様々な機能があります。これら の機能は、ユーザーが適切な予約方法を選択できるよう、個別にまたは組み合わせて使用するこ とができます。機能については次のとおりです。
設定ガイド 事前申請： TMC 統合 13
予約の切り替え： この機能は、構成済の要件と照らし合わせて旅程を評価し、対象 の出張が旅行会社によって予約されたものか、出張予約で自己予約されたものかを判断 します。
詳しくは、設定ガイド「事前申請： Booking Switch」 をご参照ください。 オフライン / オンライン ポリシー設定の強化： この機能は、ユーザーが [予約の 切り替え] から提案された予約方法を避けることを許可するかどうかを設定することに より、[予約の切り替え] で定義された要件を強化します。
手入力による申請作成を防止： この機能は、ユーザーに強制的に出張予約で処理を 開始させることで（「予約から承認」の処理フロー）、事前申請で新規申請を作成する
ことを防止します。この機能はポリシーごとに構成します。セクション 10: 出張および承認の有効期限
出張の有効期限および承認期限
承認期限は会社の出張予約の構成の一部として、出張予約で構成します。承認期限は自動キャン セル設定が有効である必要があります。事前申請が出張予約と統合済の場合、出張の有効期限に まつわる出張予約の設定が適用されます。
自動キャンセルのタイミングについて次の点に注意してください。
標準の時間枠は、「定義された時点の約 6 時間後」です（例: LDT（チケット発行
の最終日）の後、承認者による却下の後、または出張がユーザーによって破棄された後）。
特定の場合は、別の要素も考慮されます（出発の 24 時間以内）。
これは、特定の自動キャンセル設定に対してのみ、また、前述の時間枠のいずれか 1 つ よりも前に出発の 24 時間前に達する場合にのみ適用されます。
有効にすると、LDT が経過して約 6 時間後に、Concur が出張をキャンセルします。
有効にしない場合、Concur は出張をキャンセルしませんが、LDT が経過したため、GDS が実行
します。そのため、ユーザーは、LDT の経過後に出張予約で出張を完了することはできません。NOTE: 出張と承認が同じ日の予約は、予約の 30 分以内に自動キャンセルされます。
自動キャンセルおよび申請
既定では、申請承認者は定義された承認期限の後でも申請を承認することが可能でした。たとえ
ば、事前申請と出張予約が統合していると仮定します。ユーザーは申請済の出張を作成するため、出張予約にアクセスします。出張予約は、申請が特定の日付までに承認されなければキャンセル されることをユーザーに通知します。ユーザーは関連の申請を事前申請で提出してありますが、
何らかの理由によって申請承認者が期限内に承認しなかったとします。
既定では、承認者は期限の最終日を過ぎても申請を開いて承認することが可能でした。申請のワ
ークフローを使用し、申請の管理者は期限後の承認を防止するワークフロー ステップ ルールを 作成することができます。
詳しい情報は、設定ガイド「事前申請： ワークフロー - 概要」をお読みくださ い。セクション 11: オフライン PNR の要件
[オフライン PNR 取得] 機能を使用して PNR を事前申請にインポートする場合、TMC は以下の 要件を満たしている必要があります。
TMC は、適切な出張構成と CLIQCID の [オフライン承認順番待ち] と [オフライン承認エラー
順番待ち] を設定する必要があります。出張申請のオフライン PNR の取り扱いは必ずこの [オ
フライン承認順番待ち] に待機させます。シナリオ構成
事前申請と [オフライン PNR 取得] の統合は次の 2 つの構成シナリオをサポートしています。
1. TMC は PNR を [オフライン承認順番待ち] にのみ配置します。Concur はこのシナリオ を推奨しています。
2. TMC は PNR を [オフライン承認順番待ち] および [レポート順番待ち] の両方に配置し ます。このシナリオは追加の構成や処理ステップが必要になります。
[TMC ステップの更新を承認待ちの旅程のみに制限する] のサイト設定がアクティブ である必要があります。
チケットが承認され発行された場合に限り、TMC は PNR を [レポート順番待ち] に 並ばせる必要があります（申請が承認された場合など）。
必須行
この PNR を正しいユーザーおよび正しい出張申請に割り振るため、各オフライン PNR に次の 4 行（すべての GDS）を含めてください。
1. CliqCID は会社レベルのプロファイル / BAR / Level1 star に保存する必要があります。
2. プロファイル同期あり： CliqUser ID は既にプロファイル内にあります プロファイル同期なし： CliqUser ID を追加する必要があります 3. Travelrequest ID
4. 注釈「modified by agent」
形式は GDS により様々です。
設定ガイド 事前申請： TMC 統合 15
NOTE: 本ガイドの例で使用された値（CLIQCID に対して 2424 など）は、すべて仮の値です。C
LIQCID 番号は、Concur 導入プロジェクト マネージャーから提供されます。
Amadeus 形式 値の例
CLIQCID: 2424ログイン: [email protected] 申請 ID: 33HG
注釈: Modified by agent
例
1. CliqCID: RM*CLIQCID-2424
2. CliquserID: RM*[email protected]
3. TravelrequestID: RM* TRAVELREQUESTID-33HG 4. 注釈: RM*MODIFIED BY AGENT
A
MADEUSの注意
すべての PNR はオフライン承認順番待ちに並びます。
オフライン承認順番待ちは PCC の予約にて設定する必要があります。
Sabre 形式 値の例
CLIQCID: 2424ログイン: [email protected] 申請 ID: 33HG
注釈: Modified by agent
例
1. CliqCID: CR – 5.CLIQCID-2424
2. CliquserID: CR – 5.CLIQUSER-WILLIAM.NEVER¤CONCUR.COM
4. 注釈: CR – 5R‡MODIFIED BY AGENT
Galileo 形式
GIDS および順番待ちは、Concur にオフライン PNR を送るよう設定する必要があります。Concu
r は必須セグメントに関して、2 つの異なる形式を必要としており、ひとつは GIDS で読める形 式、もうひとつは事前申請で読める形式です。出張申請 ID および「modified by agent」に関 する情報は、出張申請ワークフローで提供される必要があります。たとえば、これらの行に GIDS バージョンは必須でないため存在しません。
値の例
CLIQCID: 2424ログイン: [email protected] 申請 ID: 33HG
注釈: Modified by agent
例
1. CliqCID: 請求書の注釈および履歴のメモ帳注釈を、Cliqbook の会社 ID がある BAR に 追加します。
GIDS:
DI.FT-CLIQCID-2424 順番待ち:
NP.H**CLIQCID-2424
2. CliquserID: プロファイル同期が有効な場合、出張予約は出張者のログイン ID がある 出張者プロファイル（PAR）に請求書の注釈を記載します。プロファイル同期が有効でな い場合、TMC はこの行に記入する必要があります。
GIDS:
DI.FT-CLIQUSER-William.Never//concur.com
順番待ち:
NP.H**CLIQUSER-William.Never//concur.com 3. TravelRequestId：
順番待ち:
NP.H**TRAVELREQUESTID-33HG 4. 注釈：
順番待ち:
NP.H**modified by agent
設定ガイド 事前申請： TMC 統合 17
G
ALILEOの注意
PCC の予約に対し、GIDS を設定する必要があります。Concur 導入プロジェクト マ
ネージャーが Travelport のチケットを作成します。
すべての PNR はオフライン承認順番待ちに並びます。
オフライン承認順番待ちは PCC の予約にて設定する必要があります。
Worldspan 形式 例
1. CliqCID: UDID または a 5.Z のいずれかの注釈は、経営管理部門でどのように反応する ようプログラムされているかによって決まります。
2. CliquserID: 適用可能な GDS 注釈のプレフィックス、そして CLIQUSER-<ログイン ID>
3. TravelrequestID: UDID または a 5.Z のいずれかの注釈は、経営管理部門でどのように
反応するようプログラムされているかによって決まります。
4. 注釈: 5.RMODIFIED BY AGENT
Apollo 形式
値の例
CLIQCID: 2424ログイン: [email protected] 申請 ID: 33HG
注釈: Modified by agent
例
1. CliqCID: T-S97-CLIQCID-2424
2. CliquserID: T-S98-CLIQUSER-WILLIAM.NEVER¤CONCUR.COM
3. TravelrequestID: ¤:5A/TRAVELREQUESTID-33HG 4. 注釈: ¤:5A/MODIFIED BY AGENT
オプション行
ポリシー準拠
オフライン PNR 取得から申請に到達した出張およびセグメントはポリシー準拠情報を含みます。
TMC によって PNR に追加された正式なフラグで Concur がセグメント フィールドを入力します。
この情報は POLICYCOMPLIANT とラベル付けされた外部注釈をとおして、保存および送信が必要 です。値には Y と N があり、システムはこれをポリシー準拠申請セグメント フィールドの 0-1 00 のスケール値に対応付けます。旅程が準拠している時は値が 0 （Y）になり、準拠していなけ れば 100 （N）になります。
AMADEUS 形式
注釈: RM*POLICYCOMPLIANT-N SABRE 形式
注釈: CR – 5R‡POLICYCOMPLIANT-N GALILEO 形式
注釈：
順番待ち: NP.H**policycompliant-n
WORLDSPAN 形式注釈: 5.RPOLICYCOMPLIANT-N APOLLO 形式
注釈: ¤:5A/POLICYCOMPLIANT-N
設定ガイド 事前申請： TMC 統合 19
