---
sourceDocument: 横浜ファイナンス&サプライチェーン
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/source-to-pay-operations

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - 横浜ファイナンス&サプライチェーン

ft:clusterId :

    - stpop

bundleId :

    - stpop

workflow :

    - Creator


---

# 調達要求

# 調達要求 {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：8分

ソーシング要求は、購入者、従業員、または要求者が必要とするアイテムを調達する必要がある場合に作成されます。このレコードは、購入者が購入しようとしている製品の有効な契約価格が存在しない場合に作成されます。これには、製品カタログとカタログ外の両方のアイテムが含まれます。
購入明細が作成され、ソーシング要求にグループ化されます。ソーシング要求は製品モデル別にグループ化されます。  
調達スペシャリストまたはソーシングマネージャーとして:

* Source-to-Pay ワークスペースからのすべてのソーシング要求を表示するには、 すべて調達ケース管理Source-to-Pay ワークスペースをクリックし、リストアイコン (![リストアイコン。]()) を選択し、続いて チームのすべての作業調達要求.
* プラットフォームからのすべてのソーシング要求を表示するには、 ソーシングと調達オートメーションすべての作業をクリックし、\[ All Sourcing Requests (すべてのソーシング要求)\] を選択します。
* プラットフォームからアサインされたソーシング要求を表示するには、 ソーシングと調達オートメーション自分の作業をクリックし、\[ My Sourcing Requests (自分のソーシング要求)\] を選択します。
{#sourcing-request__ul_kdw_gdt_flb}  
購入者が ShoppingHub からカタログまたはカタログ以外のアイテムを要求すると、購入者が提供した情報は次のようにソーシング要求のフィールドにマッピングされます。 {#sourcing-request__table_x3l_cdt_flb__entry__2}

| フィールド | 説明 |
|-|-|
| 番号 | ソーシング要求のシステム生成の一意の識別子。 |
| アサイン先 | 購入に対して責任を負うユーザー。購入アサインルールを使用して決定されます。 詳細については、「[購入アサインルールの作成](https://servicenow-prod.fluidtopics.net/~i55WDHbGO9NIxXsqpnlcQ "購入アサインルールを使用して、事前定義された条件に基づいて、調達要求、交渉、または購入要求を調達スペシャリストユーザーまたはタスク履行者グループに自動的にアサインします。")」を参照してください。 |
| 事業主 | ソーシング要求を所有するユーザー。 |
| 更新者 | 買い物をして購入を送信したユーザー。 |
| ステータス | ソーシング要求のステータス。 注: これは読み込み専用フィールドです。 |
| 購入 | 関連する購入 (ある場合)。 |
| ソーシングイベント | 各サプライヤーとの交渉に必要なソーシングアクティビティのタイプを表し、各サプライヤーとの個々の交渉を追跡します。 |
| 簡単な説明 | ソーシング要求の簡単な説明。 |
| サマリーの詳細 ||
| 製品カテゴリ | このソーシング要求を通じて調達された製品カテゴリ。 |
| 製品モデル | このソーシング要求を通じて調達された製品モデル。 |
| 製品名 | 要求された製品。 |
| 製品タイプ | 製品のタイプが物品またはサービスかどうかを示します。 |
| サプライヤー応答のクローズ | サプライヤーが調達アクティビティへの応答を送信する必要がある日付。 |
| ベンチマーク価格 | このソーシング要求のすべての購入明細のすべての開始単価の導出元となる価格ポイント。 |
| 要求タイプ | 購入者、従業員、または要求者が求めている要求のタイプ。オプションは、見積もり依頼、情報要求、提案依頼、概念実証です。 |
| 調達要求の詳細 | ソーシング要求の詳細。 |
[表 : 1. ソーシング要求フィールド]

{#sourcing-request__table_x3l_cdt_flb}

ソーシング要求レコードの関連リストは次のとおりです。
{#sourcing-request__table_svr_qws_flb__entry__2}

| 関連リスト | 説明 |
|-|-|
| 購入明細 | 参照されたサプライヤーのソーシング要求の下にある個々の明細の情報を提供します。 ソーシング要求の購入明細の数は、同じ製品モデルの製品またはサービスの数によって異なります。 詳細については、「[購入明細](https://servicenow-prod.fluidtopics.net/PJDAuGm~F4T5I7ZPx3nFEQ "購入明細は、参照されたサプライヤーの購入要求またはソーシング要求の下にある個々の明細の情報を提供します。")」を参照してください。 |
| 購入タスク | ソーシング要求に関連するすべての購入タスクの情報を提供します。関連付けられた交渉のタスクは表示されません。 詳細については、「[購入タスクと調達ケース](https://servicenow-prod.fluidtopics.net/TIrXFB~~C0bMCjIi1vcGWA "自動化された購入タスクと調達ケースはすべて、Service Delivery Common (SDC) アプリケーションからフローデザイナーを使用して作成されます。フローデザイナーは、基礎となるタスクとケース生成のディシジョンテーブルを使用し、ディシジョンテーブルで定義された条件に基づいて購入タスクと調達ケースが作成されます。")」を参照してください。 |
| ケース | このソーシング要求に関連付けられているすべてのケースを表示します。 |
| 購入 SLA | ソーシング要求に対する購入タスクに関連付けられた SLA と、基礎となる購買要求明細に関連付けられたタスクを表示します。 |
| 交渉 | 購入者が要求した製品またはサービスの価格設定を取得するか、条件を交渉するタスクを表します。 詳細については、「[交渉](https://servicenow-prod.fluidtopics.net/wY9SESPvv2FkzL0MSvfUpA "交渉は個々のサプライヤーの交渉を表し、サプライヤーに応じてアイテムとアクティビティを追跡します。これらのアクティビティには、購入者が要求した製品やサービスの価格を取得したり、条件を交渉したりすることが含まれます。")」を参照してください。 |
| ドラフト契約 | このソーシング要求に関連付けられたドラフト契約をすべて表示します。 詳細については、「 [契約」](https://servicenow-prod.fluidtopics.net/_6iKOGi7tdYH3W60clHZ5g "契約は、サプライヤーと製品について合意した価格とともに、契約条件を定義します。有効な契約価格は、製品またはサービスの価格設定が ShoppingHub に表示されるかどうかを決定します。")を参照してください。 |
| 署名済み契約 | このソーシング要求に関連付けられたすべての署名済み契約を表示します。 |
| その他の法務ドキュメント | このソーシング要求に関連付けられた他のすべての法務ドキュメントを表示します。 |
| 契約要求 | このソーシング要求に対して関連付けられたすべての契約要求を表示します。 注: このフィールドは、契約管理プロプラグイン (com.snc.sn_spend_clm) がインストールされているSource-to-Pay オペレーションがある場合にのみ表示されます。 |
| 承認プラン | このソーシング要求に対して作成されたすべての承認計画を表示します。 |
| ドラフトメール | ドラフトとして保存されている、関連するメール通信。 |
| 送信済みメール | 送信済みの関連するメール通信。 |
[表 : 2. ソーシング要求関連リスト]

{#sourcing-request__table_svr_qws_flb}

## ソーシングと交渉のワークフロー {#sourcing-request__section_bkg_31x_y1c}

ソーシング要求が作成された後、調達スペシャリストはサブタイプ \[Ask a Question (購入 者に詳細が必要かどうかを尋ねる)\] の購入タスクを作成できます。

調達スペシャリストは、この購入の交渉を作成できるかどうかを決定できます。交渉に時間が許せない場合は、価格の詳細についてサプライヤーに直接連絡することができます。サプライヤーが見積もりを返信した後、購入タスクが体系的に作成され、認定するサプライヤーを選択するよう購入者が求められます。これはサブタイプの調達タスクです サプライヤー を選択。認定サプライヤーの場合、購入明細の \[Awarded (認定)\] 列の値は自動的に \[Yes (はい)\] に設定され、関連する購入要求が作成されます。

購入者は \[Cancel (キャンセル)\] を選択して、ソーシング要求とそれに関連する購入明細のステータスを \[Closed Canceled (キャンセルしてクローズ)\] に更新できます。

## ソーシング要求の状況フロー {#sourcing-request__section_pb4_rvt_c1c}

認定が必要な単純なシナリオを考えてみましょう。価格が購入明細 (PRL) に入力された場合、PRL は価格が追加または更新されたことを示し、\[Pricing Obtained (価格設定取得済み)\] ステータスに移行します。このステータスはそのままです。価格とソーシング要求 (SR) のない他のすべての PRL は、引き続き \[Qualification Needed (認定が必要)\] ステータスのままになります。認定されると、\[認定が必要\] ステータスにある SR およびその他の PRL は \[認定済み\] ステータスに移行しますが、価格を設定した PRL は \[価格設定を取得しました\] ステータスのままになります。

新しい PRL を手動で作成すると、認定フローが再トリガーされます。この PRL に価格設定が追加された場合、認定作業の実行中、PRL は \[価格設定取得済み\] ステータスのままになります。また、必要に応じて、SR は \[認定が必要\] ステータスのままになります。  
ソーシングフローでソーシングイベント (NE) と交渉 (NEG) を考慮する場合は、次のシナリオを検討してください。

* 認定が必要 (Qualification is required) の場合、NE が \[計画済み\] ステータスで、NEG、SR、および PRL のステータスはすべて \[認定が必要 (Qualification Needed)\] ステータスです。価格が PRL に入力された場合、PRL は価格が追加または更新されたことを示し、\[価格設定を取得しました\] ステータスに移行し、そのステータスのままになります。価格と SR のない他のすべての PRL は、引き続き \[認定が必要\] ステータスのままになります。認定されると、\[認定が必要\] ステータスにある SR およびその他の PRL は \[認定済み\] ステータスに移行しますが、価格を設定した PRL は \[価格設定を取得しました\] ステータスのままになります。

* NEG は進行中で、NE は WIP で、NEG、SR、および PRL はすべて \[Negotiation in Progress (交渉中)\] ステータスです。NEG の進行中に価格が PRL に入力された場合、PRL は価格が追加または更新されたことを示し、\[価格設定取得\] ステータスに移行し、そのステータスのままになります。価格のない他のすべての PRL と NEG および SR は \[Negotiation in Progress\] ステータスのままですが、NE は WIP のままです。

* NE が WIP で、NEG、SR、および PRL がすべて \[Negotiation in Progress (交渉中)\] ステータスの場合、NE で \[ Start netitiating (交渉の開始)\] が選択された後に、新しい SR またはサプライヤーが追加されます。

  これにより、影響を受ける PRL で評価される認定ケースがトリガーされ、NEG が \[認定が必要\] に移動します。認定が不要な場合、NEG と新しく作成された PRL の両方が \[交渉中\] ステータスのままになります。

  認定が必要な場合、新しい SR または既存のサプライヤーが追加されても、NE は WIP に残ります。認定ケースが完了すると、NE で \[ 交渉を開始 \] を再選択しなくても、個々の NEG は自動的に \[認定済み\] から \[交渉中\] に移行します。新しく評価された PRL も \[進行中の交渉\] に移行します。

  ただし、新しく作成された PRL のいずれかに価格が入力された場合、PRL は価格が追加または更新されたことを示し、「価格設定取得済み」ステータスに移行し、そのステータスのままになります。
{#sourcing-request__ul_jym_y1w_c1c}  
ソーシング要求で利用可能なデフォルトのステータスが一覧表示されます。

* 承認待ち
* レビュー待ち
* 情報が必要
* 必要な認定
* 資格認定済み
* 交渉を保留中
* 交渉中
* 再送信を保留中
* サプライヤーの応答待ち
* タスクの完了待ち
* 決定が必要
* 完了してクローズ
* 決定なしでクローズ
* キャンセルしてクローズ
* 却下してクローズ
{#sourcing-request__ul_o34_5pz_bcc}

NEG と NE の詳細については、それぞれ「 [交渉](https://servicenow-prod.fluidtopics.net/wY9SESPvv2FkzL0MSvfUpA "交渉は個々のサプライヤーの交渉を表し、サプライヤーに応じてアイテムとアクティビティを追跡します。これらのアクティビティには、購入者が要求した製品やサービスの価格を取得したり、条件を交渉したりすることが含まれます。") 」と「 [ソーシングイベント](https://servicenow-prod.fluidtopics.net/TjtPmPb5vpbdpsMOMI3dHQ "ソーシングイベントは、各サプライヤーとの交渉に必要なソーシングアクティビティのタイプを表し、各サプライヤーとの個々の交渉を追跡します。これらは、ソーシングマネージャーが複数のサプライヤーや複数の製品の交渉を管理するのに役立ちます。") 」を参照してください。

サプライヤー階層化アセスメントタスクが SR ステータスに与える影響については、「 [ソーシングと調達オペレーション と サードパーティリスク管理との統合](https://servicenow-prod.fluidtopics.net/t_nu5wHmcqqv~QQ_ySZIbw "ソーシングと調達オペレーションをサードパーティリスク管理と統合することで、関連するサプライヤーリスクアセスメント機能を活用します。")」を参照してください。

