機能階層（製品共通）

(1)

機能階層（製品共通）

設定ガイド

最終更新日:2018 年 2 月 28 日

以下のコンカーソリューションに適用されます。

 Expense

 Professional/Premium edition

 Integrated with Professional/Premium Travel  Stand-alone

 Standard edition

 Integrated with Standard Travel  Stand-alone

 Travel

 Professional/Premium edition

 Integrated with Professional/Premium Expense  Integrated with Professional/Premium Request  Stand-alone

 Integrated with Standard Expense  Stand-alone

 Invoice Management

 Integrated with Professional/Premium Expense  Stand-alone

 Authorization Request (formerly Travel Request)

 Integrated with Professional/Premium Expense  Integrated with Professional/Premium Travel  Stand-alone

(2)

(3)

改訂履歴

日付 注意事項 / コメント / 変更内容

2018 年 2 月 28 日フィールドをリストとして追加することについての情報を追加しました。

2018 年 2 月 8 日ガイド「Employee Import Specification（製品共通）」のガイド名を更新しました。

2018 年 2 月 5 日著作権とその他の変更を更新しました。内容の変更はありません。

2016 年 12 月 14 日著作権と表紙を更新しました。その他の内容の変更はありません。

2016 年 10 月 27 日コンテンツを新様式に更新しました。内容の変更はありません。

2016 年 1 月 25 日 Analysis/Intelligence のガイドへの参照を変更しました。内容の変更はありません。

2016 年 1 月 25 日インポート / 抽出の仕様のガイドへの参照を変更しました。その他の内容の変更はありま

せん。

2015 年 5 月 15 日スクリーンショットを現行の UI に更新しました。内容を一部更新しましたが大幅な変更

はありません。

2015 年 4 月 17 日 Concur Insight の名称を Analysis/Intelligence に変更しました。そのほかの内容の変更はありません。

2014 年 11 月 30 日統合管理者がインポート/抽出管理者に変更されました。そのほかの内容の変更はありませ

ん。

2014 年 10 月 3 日 2 種類のユーザーインターフェースについての情報を追加しました。そのほかの内容の変

更はありません。

2014 年 3 月 5 日 Analysis/Intelligence の名称が Concur Insight に変更されたことを記載しました。そのほかの内容の変更はありません。

2014 年 1 月 23 日表紙と著作権を変更しました。そのほかの内容の変更はありません。

2013 年 2 月 27 日名称を Travel Request から Request に変更しました。そのほかの内容の変更はありませ

ん。

2012 年 12 月 28 日商標を変更し、著作権を更新しました。内容の変更はありません。

2012 年 10 月 19 日出張申請原価対象の承認者階層に関する情報を追加しました。

(6)

日付 注意事項 / コメント / 変更内容

2012 年 9 月 14 日請求書支払先の従業員アクセス階層に関する情報を追加しました。

2012 年 1 月 20 日請求書処理の経路階層に関する情報を追加しました。

2011 年 8 月 12 日事前申請承認権限者階層に関する情報を追加しました（出張申請が対象）。

2011 年 2 月 25 日「Shared: Feature Hierarchies and Group Configurations」を、本ガイドと設定ガイド

「従業員用グループ構成（製品共通）」に分割しました。

2010 年 12 月 31 日著作権を更新し、商標を変更しました。内容の変更はありません。

(7)

機能階層

セクション 1: アクセス許可

この機能へのアクセス権があるかどうかは場合によります。たとえば、特定のグループに対してのみアクセス権がある、または読取専用で作成や編集はできないなど、限定的なアクセス権を持っている場合があります。

管理者はこの機能を使用する必要がありますので、適切なアクセス権がない場合は、社内の Concur 管理者に連絡してください。

さらに、このガイドに記載されている作業は Concur にのみ許可されているものもあります。必要に応じて Concur クライアントサポートにご依頼ください。

セクション 2: 概要

一部の機能には、組織チャートのような階層が定義されており、組織チャートの各レベル用にデータを提供するデータリストが関連付けられています。管理者は、この階層を基にグループ構成を定義できます。

機能階層ツールを使用して、階層のレベルを定義、編集、並び替えることができます。

機能階層

機能階層は、経費精算、請求書処理、事前申請、および Analysis/Intelligence の機能領域を管理するためのものです。一部の機能には階層が関連付けられており、この階層によって従業員グループが定義されます。たとえば、従業員の階層は一連の従業員グループを管理し、特定の従業員グループが各種の従業員フォームのうちのどの従業員フォームを使用するかを決定します。

機能階層ツールには、経費精算の管理、請求書処理の管理、または事前申請の管理からアクセスします。このページからすべての階層を構成できます。

階層が関連付けられている機能は以下の一覧のとおりです。以降のページで詳しく説明します。

(8)

従業員に関する機能:

• 従業員

経費精算に関する機能:

• 経費精算レポート

• 経費精算承認権限者

• 経費精算原価対象の承認者

• 税

• 出張手当

請求書処理に関する機能:

• 支払先への支払

• 支払承認権限者

• 支払原価対象の承認者

• 請求書の支払（Invoice Pay）に関する機能:

• 請求書支払先の従業員アクセス

Analysis/Intelligence に関する機能:

• 分析レポート

事前申請に関する機能:

• 事前申請承認権限者

• 事前申請原価対象の承認者

(9)

ソースリスト

ソースリストは、その機能階層で使用可能なグループに表示されるデータを提供します。

機能階層ツールの対象外

連結リストと勘定科目コードは階層形式ですが、機能階層ツールでは構成できません。詳しくは、

以下の文書を参照してください。

連結リストの情報 勘定科目コードの情報

設定ガイド「経費精算: フォームとフィールド」

設定ガイド「請求書処理: フィールド」

設定ガイド「事前申請: フォームとフィールド」

設定ガイド「経費精算: 元帳」

設定ガイド「経費精算: 勘定科目コード」

設定ガイド「請求書処理: 元帳」

設定ガイド「請求書処理: 勘定科目コード」

(10)

セクション 3: 機能階層の種類

従業員

従業員階層は、従業員固有のデータを管理するためのグループを設定する際に使用します。階層のレベルとして選択するフィールドを、従業員フォームに含める必要があります（このフィールドは必要に応じて非表示にできますが、フォームには必ず含める必要があります）。従業員グループを使用して、各従業員が使用可能なフォームを指定します。これらのフォームは、ユーザー管理およびプロファイルに表示されます。

従業員階層は、経費精算、請求書処理、および事前申請の管理で設定する代理の委託など、別の機能で使用する階層グループを指定する際にも使用します。

経費精算

経費精算で使用するフィールドは、以下のとおりです。

• 経費精算レポート: 経費精算レポート階層は、経費精算で使用するグループを設定する 際に使用します。従業員グループを使用して、経費精算ポリシーや従業員がアクセス可能なデータの構成を決定します。ロール管理でグループベースのロールを割り当てると

(11)

きにも、この階層を使用します。たとえば、特定の従業員グループを基にパスワードマネージャーを割り当てることができます。

• 経費精算承認権限者: この承認権限者は、経費精算、請求書処理、および事前申請で使 用可能です。それぞれ個別の階層を持っています。



承認権限者についてのさらに詳しい情報は、設定ガイド「経費精算: ワークフロー（承認権限者）」をご参照ください。

• 経費精算原価対象の承認者: 原価対象の承認者は、経費精算、請求書処理、および事前 申請で使用可能です。それぞれ個別の階層を持っています。



原価対象の承認者についてのさらに詳しい情報は、設定ガイド「経費精算: ワークフロー（承認権限者）」をご参照ください。

• 税: 税階層は、ユーザーの国と階層内での地位の組み合わせに基づいて税の構成を決定 します。国、部、または部門など、組織内での所属に応じて、従業員の制限を構成することができます。

(12)

NOTE: 税階層と出張手当階層は、その他の階層とは異なり、ユーザーを機能階層に対応付けるためにソースリストは使用しません。

税階層には、従業員フィールドリストから任意のフィールドを含めることができます。



さらに詳しい情報については、設定ガイド「経費精算: 付加価値税/税管理」をご参照ください。

• 出張手当: 出張手当階層は、ユーザーの国と階層内での地位の組み合わせに基づいて、

出張手当の構成を決定します。たとえば、ドイツの支社で研究開発部門の開発部に所属する従業員の場合、システムによって、この国と部署の組み合わせに応じた出張手当の構成が選択されます。

NOTE: 税階層と出張手当階層は、その他の階層とは異なり、ユーザーを機能階層に対応

付けるためにソースリストは使用しません。

出張手当階層には、従業員フィールドリストから任意のフィールドを含めることができます。



さらに詳しい情報は、設定ガイド「経費精算: 出張手当」をご参照ください。

請求書処理

請求書処理で使用される階層は、以下のとおりです。

• 請求書の支払: この階層は Invoice Pay 機能用です。



Invoice Pay についての詳細情報は、設定ガイド「請求書処理: Invoice Pay」

を参照してください。

• 請求書の経路: この階層は、申請を請求書の所有者に自動的に送るために使用します。

• 支払先への支払: 支払先への支払階層は、請求書処理で使用するグループを設定する際 に使用します。支払グループを使用して、請求書処理ポリシーや従業員がアクセス可能なデータの構成を決定します。ロール管理で請求書処理に関連するグループベースのロールを割り当てるときにも、この階層を使用します。

(13)

• 支払承認権限者: この承認権限者は、経費精算、請求書処理、および事前申請で使用可 能です。それぞれ個別の階層を持っています。



承認権限者についてのさらに詳しい情報は、設定ガイド「請求書処理: ワークフロー（概要）」をご参照ください。

• 支払原価対象の承認者: 原価対象の承認者は、経費精算、請求書処理、および事前申請 で使用可能です。それぞれ個別の階層を持っています。



原価対象の承認者についてのさらに詳しい情報は、設定ガイド「請求書処理: ワークフロー（原価対象承認）」をご参照ください。

• 請求書支払先の従業員アクセス: ここで作成した支払先グループ支払先に割り当てた後、

ユーザーに対応付けます。対応付けられたユーザーは、支払申請を作成するときに、このグループの支払先からのみ選択できるようになります。



ユーザーに割り当てる支払先グループの作成についての詳細情報は、ユーザーガイド「請求書処理: 従業員の支払先へのアクセス権」を参照してください。

Analysis/Intelligence

Analysis/Intelligence で使用するフィールドは、以下のとおりです。

• 分析レポート: 分析レポート機能は、管理者および従業員が、割り当てられているレポ ートグループ階層以下のレベルで、レポートを作成、表示、または削除する際に利用可能なデータを指定するために使用します。



分析レポート階層についてさらに詳しい情報は、ユーザーガイド

「Analysis/Intelligence: 概要」をご参照ください。

事前申請

事前申請で使用するフィールドは、以下のとおりです。

• 事前申請承認権限者: この承認権限者機能は、経費精算、請求書処理、および事前申請 で使用可能です。それぞれ個別の階層を持っています。

(14)



承認権限者についてのさらに詳しい情報は、設定ガイド「事前申請: ワークフロー - 承認権限者」をご参照ください。

• 事前申請原価対象の承認者: 原価対象の承認者は、経費精算、請求書処理、および事前 申請で使用可能です。それぞれ個別の階層を持っています。



原価対象の承認者についてのさらに詳しい情報は、設定ガイド「事前申請: ワークフロー – 原価対象承認」をご参照ください。

セクション 4: 機能階層の設定

推奨ステップ

機能階層を正しく設定するには、経費精算の管理、請求書処理の管理、事前申請の管理内の複数の設定画面にアクセスする必要があります。次の順番で設定することをお勧めします。

ステップ 1: 階層を設計して、使用するフィールドを決定する

最初のステップでは、機能ごとに階層構造を紙やホワイトボードに書きながら決定します。従業員から開始し、次に経費精算、それから残りのすべての階層を定義します。

以下にご注意ください。

• 階層レベル – 一度使用を開始すると削除できません。したがって、適切に設計してテストしておくことが極めて重要です。テスト環境で構造を確認している間は、いつでも必要に応じてデータを消去できます。

• 従業員の機能階層または経費精算レポートの機能階層のベースとして自社の組織構造を使用することができます。

(15)

組織構造は論理的に構成されており、一般的に、必要な連結リストのソースデータもすぐに利用可能な状態になっています。ただし「組織図」は、ほとんどの場合階層のベースとしては柔軟性がありません。特に、将来組織変更が発生する際の対応で問題が発生する可能性があります。

一度使用開始した階層は、最下層にレベルを追加する以外の変更はできないことにご注意ください。一方、実際の組織構造は定期的に変更することが一般的です。組織変更が発生した場合は、Concur お客様サポートにカスタマイズや階層の新規作成を依頼することになりますが、新しいデータが必要になる可能性があります。いずれも複雑になりやすく、コストがかります。

!

重要: どうしても必要がある場合を除き、「組織図」は使用しないことをお勧めし ます。「組織図」の構造を使用する唯一のケースは、組織構造のノードを基にグループ対応のロールを割り当てる場合です。このようなケースは極めて稀です。

このケースのベストプラクティスでは、以下で説明しているように、カスタム 21 を使用して、単一レベルのリストを持つ単一レベルの階層を設計します。

• （複数レベルの）連結リストは必要ありません。単一レベルの階層や複数レベルの階層を設計することができます。連結リスト、リスト、テキストなどのフィールドタイプを使用します。

(16)

従業員および経費精算レポートの機能階層には、単一レベルの階層が適しています。他の一部の階層については、連結リストを持つ複数レベルの階層にする必要があり、単一レベルの階層は選択できません。

フラットな（単一レベルの）リストは作成が容易で柔軟性に優れています。また、コストがかかるカスタマイズを行わなくても簡単に変更できます。従業員のグループを識別するために会社で使用している属性（会社コード、国、またはロール）を使用して、カスタム 21 のようなカスタムフィールドを作成します。

さらに、複数レベルの階層を使用する場合は、最初の 2 つのレベルに連結リストフィールド、3 番目のレベルにテキストフィールドを使用するなど、複数のフィールドタイプを組み合わせることができます。

• 組織単位フィールドを使用する必要はありません。カスタム 21 のようなカスタムフィールドの使用を検討します。組織単位フィールドを使用する場合、そのフィールドやソースデータを使用している他のフィールドと競合が発生することがあります。

• 階層のように複数の目的で同じフィールドを使用すると、設計上の競合が発生する可能性があることにご留意ください。たとえば、以下のとおりです。

 承認権限者を選択できるようにするために、会社（OU1）、コストセンター

（OU2）、および部（OU3）が必要です。

 配賦連結リストを選択できるようにするために、会社（OU1）、コストセンター

（OU2）、およびプロジェクト（Cust1）、タスク（Cust2）が必要です。

この結果、連結リストデータのセットが余分に生成されることから、同期されていない状態になる可能性もありますが、両方のニーズを満たす長い連結リストデータが生成されます（OU1、OU2、OU3、Cust1、および Cust2）。

• コピーダウンしてフィールドにデータを入力できます。従業員フィールドまたはレポートフィールドを使用できますが、次のことに注意してください。

 従業員フィールドは現在の状態を表します。

 レポートフィールドは、レポートを保存したときなど、過去のある時点の状態を反映しています。

(17)

従業員データは、レポートの提出時と承認権限者階層によって適切な承認者が判断された時点では異なる可能性があります。そのため、レポートが提出されて検証された時点のデータに基づいて経費精算レポートを送るか、従業員の現在のデータを使用するかを検討する必要があります。

• 複数のフィールドタイプと共に検証ルール（通常は、承認権限者向け）を使用できます。

たとえば、以下のとおりです。

 階層: 会社、コストセンター、ワークフロークラス

 このシナリオでは、会社とコストセンターが連結リストフィールドで、ワークフロークラスはテキストフィールドです。このテキストフィールドは、ワークフロークラスフィールドを更新するために従業員プロファイルを評価する検証ルールによって更新されます。

ステップ 2: 階層およびソースリストを作成する

（このガイドの「作業手順」で定義したように）階層を作成するときに、新しいソースリストを作成するか、既存のソースリストを作成するように求められます。ソースリストは、連結リストを定義するために必要です。この時点でリスト項目を含める必要はありませんが、インポートされた会社データを処理するためのプレースホルダとしてリストを作成しておく必要があります。

リストをリスト管理で作成した後、項目を手入力またはインポートすることができます。リストデータは、機能階層をアクティブにする前に入力またはインポートする必要があります。

!

重要: 従業員レコードのデータがリストの値に対して検証されるため、従業員をインポート するには、リストデータを入力またはインポートしておく必要があります。

ステップ 3: 元帳を設定する

階層のレベルの 1 つとして元帳を使用する場合、すべての元帳をこの時点で作成する必要があ ります。元帳をレベルとして使用しない場合、システム構成中のどの時点で作成しても構いませ ん。

(18)



原価対象の承認者についてのさらに詳しい情報は、以下をご参照ください。

 設定ガイド「経費精算: 元帳」

 設定ガイド「請求書処理: 元帳」

ステップ 4: リストデータを入力またはインポートする

リストデータは、リスト管理で手入力またはインポートすることができます。



詳細情報については、設定ガイド「リスト管理（製品共通）」をご参照ください。

ステップ 5: 連結リストの定義を作成する

連結リストの定義は、ソースリストに含まれるデータと階層タイプを関連付けます。

階層定義は、階層のレベルを構成するフィールドと、有効なグループのリストを入力するために使用するソースリストを定義します。連結リストの定義は、連結リストの定義に関連付けられているソースリストから入力するフィールドを指定します。通常、階層レベルと連結リストの定義は、同じレベルを使用することを想定します。ソースリストから、フィールドが入力され、

その結果、従業員のグループが決定します。

少なくとも従業員階層のフィールドには、従業員フォームの連結リストを使用することをお勧めします。

(19)

必須ではありませんが、連結リストの定義は階層と同じにすることができます。階層のフィールドに入力するためには、階層を作成してから連結リストの定義を作成します。この連結リストの定義は、階層と同じにする必要はなく、階層をサブセットにすることができます。階層用に連結リストの定義を用意する必要はありません。



詳しくは、以下をご参照ください。

 設定ガイド「経費精算: フォームとフィールド」

 設定ガイド「請求書処理: フィールド」

 設定ガイド「事前申請: フォームとフィールド」

ステップ 6: 連結リストの定義で使用するフィールドを指定する

連結リストの定義でフィールドを選択した後、その連結リストに関連付けられているフィールドの名前は変更することができますが、その連結リストの定義に関連付ける必要があります。



 設定ガイド「請求書処理: フィールド」

ステップ 7: フィールドをリストとして追加する

機能階層に関連付けれらたフィールドは、すべてフォーム内にリストとして追加する必要があります。

ステップ 8: フォームを定義する

エンドユーザーがフィールドにアクセスを開始する前に、従業員フォーム、経費精算フォーム、

請求書処理フォーム、事前申請フォームにエンドユーザーを関連付ける必要があります。



(20)

 設定ガイド「請求書処理: フォーム」

ステップ 9: ポリシーを作成または編集する

作成したフォームを含めるには、既定の経費精算ポリシー、請求書処理ポリシー、または事前申請ポリシーを作成または編集します。ポリシーは、ユーザーが経費精算レポート、支払申請、または申請を作成するときに使用するフォームを定義します。



 設定ガイド「経費精算: ポリシー」

 設定ガイド「請求書処理: ポリシー」

 設定ガイド「事前申請: ポリシーとグループ」

ステップ 10: 経費精算および請求書処理用のグループ構成を定義する

経費精算および請求書処理用のグループ構成を定義して、フォームとポリシーを割り当てます。

フォームまたはポリシーが異なる階層の最上位でのみ、定義する必要があります。

NOTE: 事前申請は、経費精算グループを使用します。

[グループ構成リスト] ページには、グループで利用可能でグループ固有のデータがあるすべて の機能の列が表示されます。ポリシーおよび支払タイプは、グループごとに構成する必要があります。同様に仮払ワークフロー使用する場合は、仮払ワークフローごとに構成する必要があります。この時点では、その他の列の定義は省略できます。構成中の任意の時点で定義できますが、

このページには、新しいグループが必要かどうかを判断するのに役立つすべての項目が表示されています。

(21)



 設定ガイド:「経費精算: Group Configurations for Expense」

 設定ガイド「請求書処理: グループ構成」

従業員インポートに関する注意事項

機能の設定が完了したら、従業員インポートの定義を作成してインポートを実行できます。最初の従業員インポートには、従業員データの完全なセットを使用する必要があります。このインポートでは、機能列レベルごとに対応付けられた列によって従業員がグループに割り当てられます。

インポートは、すぐに実行する必要はありません。他の構成と異なり、グループ構成の後に行う必要があります。インポートには、インポート/抽出管理者ツールを使用します。



インポートについての詳細は、「従業員インポート（製品共通）」をご参照ください。

セクション 5: 作業手順

機能階層へのアクセス



ツールにアクセスするには:

1. [管理] > [経費精算]（または [請求書処理] か [事前申請]）に進みます。

(22)

NOTE: アクセス許可によっては、[管理] をクリックしてすぐにこのページが表示されることもあります。

2. [機能階層] （左側メニュー）をクリックします。[機能階層] ページが表示されます。

階層レベルの追加

新しい機能レベル（定義）はいつでも追加できます。これらのレベルは、フィールド間の親子関係を定義します。グローバル管理者のみが、機能に階層レベルを追加できます。

!

重要: グループ構成ツールでレベルにグループ構成を割り当てた後は、そのレベルは、削除 も並べ替えもできません。ただし、階層の最下位に新しい機能レベルを追加することができます（最大 10 個）。

また、テスト環境で構造を確認している間は、いつでも必要に応じてデータを消去できます。

(23)



階層レベルを追加するには:

1. [機能階層] ページで、目的の機能を選択します。

2. [階層の修正] をクリックします。[機能の階層] ウィンドウが表示されます。

3. [ソースリスト] を作成または選択します。

 新しいリストを作成するには、[新しいソースリストの作成] チェックボックスを選択して、[ソースリスト名] フィールドに名前を入力します。

 既存のリストを使用するには、[ソースリスト] のドロップダウンから目的のリストを選択します。

(24)

4. 新しい階層レベルを作成するには [新規] をクリックします。新しい行がウィンドウに表示されます。

(25)

5. 適切な [レベル] を選択します。

(26)

6. 適切な [セグメント名] を選択します。

7. これを必要な数だけ繰り返して階層を定義します。

8. [保存] をクリックします。

階層の並べ替え

階層レベルは親子関係を定義します。従業員や経費精算などの階層のタイプ、および階層レベルを定義するフィールドのタイプに応じて、フィールドの並べ替え方法に制約が生じます。これらを反映して、レベルの並べ替えでドロップダウンから選択できる項目が決まります。たとえば、

従業員フォームとレポートエントリフォーム両方からのフィールドがある階層では、すべての

(27)

従業員フィールドを一緒にする必要があるため、入力フィールドは使用できません。また、それらのフィールドはすべて、[レポートエントリ] フィールド上になければなりません。

NOTE: 構成階層（従業員、経費精算、請求書処理、分析レポート）について、グループ構成が

定義されているレベルは並べ替えできません。構成が定義されている最後のレベル以下のレベルのみを並べ替えることができます。



階層レベルを並べ替えるには:

3. [順序] 列の矢印をクリックして、階層のレベルを上下します。

階層レベルの削除

!

重要: 使用を開始した階層レベルは削除できません。構成が定義されている最後の階層レベ ル以下のレベルのみを削除することができます。

(28)



階層レベルを削除するには:

3. 目的の階層レベルを選択します。

4. [削除] をクリックします。

階層の編集

構成階層は、システムの初期設定時に作成するのが理想的です。構成データは、異なるグループのセットに対して定義します。ただし、場合によっては構成設定の変更が必要になることがあります。変更するときは、構成データが失われないように注意する必要があります。変更時には、

以下の点について考慮することが重要です。

• グループと構成データをグローバルグループレベルでのみ定義する場合、機能階層ツールでいつでも階層を修正できます。

• 階層内のいずれか 1 つの最下層レベルにグループや構成データが定義されていない場合は、そのレベルを削除できます。

• 必要に応じて、階層の最下層レベルのすべての定義済みグループまたは構成データを削除し、そのレベルを削除できます。

• 構成階層にレベルをいつでも追加できます。

たとえば、会社 > 部門 > 部という階層を使用して経費グループを作成している場合、以下が適用されます。

• グローバルグループ以外のグループを定義しない限り、経費精算の機能で階層を自由に修正できます（例: 会社 > 国 > 部門 > 部に変更する）。

• その後、会社 = Concur、国 = ヨーロッパ、部門 = 営業というグループを定義できます。

• 上記の変更を行った後は、この階層は自由に変更できなくなります。これに対しては 2 つのオプションがあります。

(29)

 「部」の下に新しいレベルを 1 つまたは複数追加できます。

 「部」レベルは構成がないので（このレベルにはグループが定義されていないため）、削除できます。

• 階層を、会社 > 国 > 地域に変更する場合、つまり、「部門」レベルと「部」レベルを削除して、「地域」レベルを追加する場合、「部門」レベルと「部」レベルのすべてのグループ（構成データ）を削除した後、この 2 つのレベルを階層から削除します。それから、階層に「地域」レベルを追加できます。



階層レベルを編集するには:

3. 編集するフィールドを選択します。必要な変更を加えます。

セクション 6: 設定のテスト

機能階層が適切に設定されているかどうかをテストするには、以下の手順を実行します。

• グループ固有の従業員詳細をチェックします。従業員管理者としてログインするかプロ キシ経由で従業員の情報を表示します。従業員が正しいグループに属しているかを確認するには、その従業員が正しいグループに割り当てられている場合にのみ表示される特定のフィールド、経費タイプ、またはその他の情報をチェックします。

たとえば、従業員の情報にアクセスして、区域、部門、および部が正しいことを確認します。

(30)

この例では、営業グループは開発グループと異なる従業員フォームを使用しており、営業グループの従業員フォームには、開発グループの従業員フォームにはないカスタムフィールドが含まれていると想定します。ユーザー管理で営業グループの従業員を検索して、正しいフォームが表示されることを確認してください。

• 従業員インポートをチェックします。グループが正しく設定されていないと、従業員イ ンポートは失敗します。インポート/抽出管理者がリストデータをインポートするときに、[実行履歴の表示] レポートに、失敗とエラーメッセージが表示されます。

セクション 7: その他のグループ対応領域の編集または検証

新しい監査ルール、車両設定、領収書制限などを作成する場合、これらの構成を使用するグループを定義する必要があります。たとえば、特定のグループにのみ適用する監査ルールを作成できます。

また、経費精算レポートや業者の支払を作成でき、（レポートの処理やレポートの承認などの）

他のタスクを実行可能な従業員は、自身の経費精算レポートや支払申請を承認したり処理したりすることはできません。そのため、その従業員のレポートや申請を処理したり承認したりする権限を他の処理者や承認者に許可するグループを作成しておく必要があります。

セクション 8: ユーザーへの表示

機能階層のほとんどの情報は、エンドユーザーに表示されます。ただし、従業員が属するグループに基づいて、そのグループが利用可能な情報にアクセスできます。

ユーザーに表示される項目は、以下を含む機能階層に基づきます。

(31)

• ユーザーグループに基づく特定のポリシー。たとえば、営業部の従業員には営業部の制限内容に基づいて警告メッセージが表示され、マーケティング部の従業員には別のメッセージが表示されます。

• フォーム上のフィールド。たとえば、従業員のグループが税機能を使用するように設定されていない場合、[税額] フィールドは経費エントリに表示されません。

従業員データが機能に正しく対応付けられていない場合、エンドユーザーには、そのユーザーがその機能について特定のグループに割り当てられておらず、Concur 管理者に問い合わせる必要があるというメッセージが表示されることがあります。管理者は、機能階層の設定が正しいことを確認して、このエラーが発生しないように修正します。

機能階層（製品共通）