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

承認の再評価の条件と、購入の自動化への影響を確認します。

## 再アセスメントプロパティの承認を再送信 {#approvals-reassessment__section_yd5_krl_ynb}

sn_shop.approval.reassessment.resend 購入プロパティは、改訂または結合の結果として承認を再評価する必要があるかどうかを決定します。改訂は、発注書または購入要求の改訂になります。このプロパティは、同じ承認ルールがトリガーされた場合にのみ適用されます。新しいルールがトリガーされた場合、このプロパティは適用されず、新しい承認計画が生成されます。

承認ルールグループと順序付け、およびこれらがプロパティにどのように影響するかについては、「 [承認ルールのグループ化と順序付け](https://servicenow-prod.fluidtopics.net/WE82EGyGjmiEt2TyU6Ighg "調達アドミニストレーターは、承認ルールを承認グループに関連付け、これらのルールをトリガーするタイミングを決定する順序を定義できます。この関連付けにより、ルールグループ内の一連の承認ルールがすべて同時に評価されるのではなく、順番にトリガーされます。")」を参照してください。

金額がすでに出荷または配送された金額を下回っている場合、資金修正の削減は許可されません。却下された明細では改訂が許可されないため、承認の再評価は適用されません。

承認ルールの詳細については、「 [承認ルールタイプ](https://servicenow-prod.fluidtopics.net/oeebWCDVk5POzoy5ybTTNg "承認ルールタイプは、購入要求プロセス中に承認を作成する方法を決定します。") と [承認ルールの作成](https://servicenow-prod.fluidtopics.net/GhB3FABXnqAm_8jTzLXNQw "承認戦略を定義し、承認ルールを作成して、購入要求、発注書、ソーシング要求、請求書を承認します。これは、組織が必要とするあらゆる種類の承認プロセスを推進できる一元的な構成です。")」を参照してください。

承認の再アセスメントが承認者に送信される場合、考慮される承認金額には、改訂された明細の元の金額と資金の増加が含まれている必要があります。たとえば、元の明細金額が 1000 ドルで、資金改訂の増加により明細金額が 1500 ドルになった場合、再評価と承認のために考慮される金額は 1500 ドルです。

アセスメントの承認を再送信プロパティが \[はい\] に設定されている場合、進行中の既存の承認計画レコードがあり、計画が完了する前に改訂または結合が行われた場合、そのステータスは \[不要\] に更新され、新しい計画が作成されます。プロパティが \[いいえ\] に設定されていて、既存の承認計画が進行中の場合は再利用されます。

承認の再アセスメント中は、完全受領済みラインを却下することはできません。ShoppingHub では、完全受領済み明細が \[承認済み \] タブに表示されます。

## 承認時の期日の入力 {#approvals-reassessment__section_xjm_wxk_ynb}

新しい承認レコードが生成され、承認レコードのステータスが \[要求済み\] になると、次のプロパティを使用してレコードの期日が計算され、入力されます。

* sn_shop.pr.approval.duration:承認要求を完了するために承認者に割り当てられる期間 (時間)。デフォルトでは 9 時間に設定されています。
* sn_shop.pr.approval.duration.schedule:承認期間に関連付けられたスケジュールのタイプ。デフォルトでは、休日を除く平日の 8 〜 5 時に設定されています。  
  注:  
  スケジュールのsys_idがこのプロパティの値として使用されます。
{#approvals-reassessment__ul_ojg_y2l_ynb}

並列承認レコードの期日は同じです。順次承認の場合、最初の承認者の期日は定義されたプロパティ値に基づいて入力され、2 番目の承認者の期日は最初の承認が完了した後に計算されます。

## 違反承認レビュータスクの作成 {#approvals-reassessment__section_vwb_m2l_ynb}

承認の期日に違反した場合、1 日に 1 回実行される \[PSM\] 承認期日違反スケジュール済みジョブを使用して、新しいタスクが自動的に作成されます。このタスクは、サブタイプが \[Approval (承認)\] の購入タスクであり、購入要求がアサインされているのと同じ人物にアサインされます。

順次承認の場合、この購入タスクは期限切れの承認者レコードごとに作成されます。並列承認の場合、違反したすべての関連承認者レコードを表示する関連リストとともに単一のタスクが作成されます。

このタスクの期日には、違反承認レビューの SLA 定義に関連付けられた SLA インスタンスレコードの違反時間が入力されます。

不要になった承認またはキャンセルされた承認の場合、違反承認レビュータスクの作成はトリガーされません。違反承認レビュー SLA は不要になったため削除されます。