---
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) 所要時間：5分

特定の基準が満たされた場合、購入要求を結合できます。これにより、複数の発注書 (PO) が不必要に作成されることが回避され、承認ルールの制限を適用するのにも役立ちます。

購買要求のグループ化について、次のさまざまなシナリオを検討してください。

## 購入要求をマージするシナリオ {#purchase-requisition-merging__section_ltb_gbj_rlb}

調達バイヤーは、同じサプライヤーの新製品を既存の要求にグループ化して、複数の注文がサプライヤーに送信されないようにすることができます。次のシナリオを考えます。  
シナリオ 1:サプライヤー A の購買要求 (PR1) が存在し、ステータスが \[Pending Approval (承認待ち)\] である。発注書 (PO) が作成されていません。

* ソーシング不要:購入者が ShoppingHub で同じサプライヤー A からサプライヤー製品を追加し、その製品に PR1 と同じ送信者、サプライヤー、コストセンター、およびビジネスオーナーが設定されている場合、明細は自動的に PR1 とグループ化され、ステータスは \[Pending Approval (承認待ち)\] になります。PR1 は \[承認待ち\] ステータスのままです。承認はリビジョンと同様に再評価されます。明細が PR1 から 24 時間以上後に作成された場合、自動的にグループ化されず、新しい購買要求の下に作成されます。

* ソーシングが必要:購入者が ShoppingHub の同じサプライヤー A から有効な契約価格のないサプライヤー製品を追加すると、ソーシング要求が作成されます。ソーシング要求で、明細が同じサプライヤー A に発注され、同じ送信者、サプライヤー、コストセンター、およびビジネスオーナーを含む既存の購買要求があり、新たに調達された明細が PR1 から 24 時間以内に作成されたと仮定すると、サプライヤーが受注した時点で購入明細は PR1 を参照します。 購入要求が作成されます。明細が \[承認待ち\] ステータスで PR1 に追加されます。PR1 は \[承認待ち\] ステータスのままです。承認はリビジョンと同様に再評価されます。

{#purchase-requisition-merging__ul_b53_rbj_rlb}  
シナリオ 2:サプライヤー A の PR1 が存在し、ステータスが \[Awaiting Task Completion (タスク完了待ち)\] である。PO はまだ存在しません。

* 調達スペシャリストは、購入要求を手動で結合する必要があります。
* ソーシング不要:
  * PR2 のヘッダーに、この購入要求を別の既存の要求 \<購入要求番号\> と結合できることを示す注釈が表示されます。ここで、\<購入要求番号\>は、PR2 と同じ送信者、サプライヤー、コストセンター、およびビジネスオーナーを持つ PR1 へのリンクです。この注釈は、PR1 に対して注文が作成されるとクリアされます。
  * ユーザーは、PR2 ヘッダーで \[マージ\] を選択して、明細行を PR2 から PR1 に移動できます。PR2 が属する購買要求に属する他の要求またはソーシング要求がない場合、購買要求と PR2 は削除されます。結合された明細のステータスは \[Pending Approval (承認待ち)\] になり、購入要求も \[Pending Approval (承認待ち)\] に戻ります。ただし、元の行は元のステータスのままです。承認はリビジョンと同様に再評価されます。
  * 購買要求 2 に他の要求またはソーシング要求があった場合、その購買要求は削除されません。購買要求 2 のみが削除されます。
  * 結合 UI アクションは、PR2 と対応する明細が PR1 から 24 時間以内に作成された場合にのみ使用できます。
  {#purchase-requisition-merging__ul_ds1_v2j_rlb}
* Sourcing required (ソーシングが必要): ソーシング要求を付与すると、この明細を別の既存の要求 \<購入要求番号\> と結合できることを示す同様の注釈がソーシング要求のヘッダーに表示されます。ユーザーは、\[ 既存の要求と結合 \] または \[ 要求を作成\] を選択できます。結合されると、PR1 のステータスは \[承認待ち\] に戻ります。
{#purchase-requisition-merging__ul_lh1_k2j_rlb}

シナリオ 3:サプライヤー A の PR1 が存在し、ステータスが \[Final Review (最終レビュー)\] である。PO はまだ存在しません。シナリオ 2 と同じです。

シナリオ 4:PR1 のステータスが \[タスク完了待ち\] で、PR2 が PR1 と結合されておらず、ステータスが \[承認待ち\] です。別の購入が作成されます。調達スペシャリストが PR2 と PR1 を結合しないことを決定し、PR2 のステータスが \[Pending Approval (承認待ち)\] のままである場合、シナリオ 1 の基準に従って新しい購入明細が PR2 と自動的に結合されます。  
シナリオ 5:複数の PR が \[タスク完了待ち\] または \[最終レビュー\] ステータス。同じ要求者、サプライヤー、コストセンター、およびビジネスオーナーで 24 時間以内に作成された新しい PR。

* ユーザーが新しい購入要求で \[Merge (マージ )\] を選択すると、ステータスが \[Awaiting Task Completion (タスク完了待ち)\] または \[Final Review (最終レビュー)\] のすべての購入要求のリストが表示され、結合するものを選択できるようになります。
* このシナリオでは、最新の購入要求に、この購入要求を他の複数の要求と結合できることを示す注釈が表示されます。
{#purchase-requisition-merging__ul_w3q_l3j_rlb}  
シナリオ 6:リビジョン

* PO 改訂の結果として作成されたリビジョンタイプの購買要求は、マージの対象にはなりません。
* PO が作成されない購買要求リビジョンは、前のシナリオで文書化された同様の基準を使用してマージすることを検討できます。

{#purchase-requisition-merging__ul_zcn_53j_rlb}  
注:  
すべてのマージシナリオで、 マージ は最後に作成された購入要求のUIにのみ表示されます。

シナリオ 7:サプライヤー A の PR1 が存在し、ステータスが \[Closed Canceled (キャンセルしてクローズ)\]、\[Closed Rejected (却下してクローズ)\]、または \[Closed Complete (完了してクローズ)\] である。明細は、ステータスが \[キャンセルしてクローズ\]、\[却下してクローズ\]、または \[完了してクローズ\] の PR にグループ化されません。代わりに、新しい PR が作成されます。

シナリオ 8:PO が既に作成されており、同じサプライヤーのサプライヤー製品が追加されています。新しい購入要求と購入要求 (PR2) を作成します。

## 購入明細の結合 {#purchase-requisition-merging__section_cgn_fjj_rlb}

購入要求内の購入明細は、次の条件で結合することもできます。

* 数量を除き、サプライヤー製品、ビジネスオーナー、コストセンター、送信者、配送日または開始日/終了日、配送場所、支払方法、購入理由が同一の場合、購入明細を別々の明細ではなく 1 つの明細にグループ化できます。
* 配送日、開始日/終了日、または配送場所が異なる場合は、新しい明細を作成する必要があります。
* 支払方法のみが異なる場合は、結合比率に基づいて、それに応じてコスト割り当てエントリを更新する必要があります。
* 購入理由のみが異なる場合は、次のように購入理由を追加します。
  * 購入理由 1 - 数量 1 (例:新規雇用オリエンテーション - 数量 10)
  * 購入理由 2:数量 2 (例:IT ハードウェアの更新 - 数量 2)
  {#purchase-requisition-merging__ul_fqx_mjj_rlb}
{#purchase-requisition-merging__ul_l14_3jj_rlb}  
注:  
購入要求のマージと購入明細のマージは、バンドル製品には適用されません。