PO変更承認
このページは機械翻訳を使用して翻訳されています。
この記事では、PO変更リクエストの承認チェーンにユーザーを追加することの利点と「ハウツー」について説明します。
インスタンスは、ユーザーが発注書の変更をリクエストできるように設定されている場合とされていない場合があります。PO変更のデフォルト設定では、POへの変更の元の申請承認チェーンが含まれます。変更リクエストが元の承認者の承認額を超えると、適切な承認額を持つ他の誰かが変更リクエストに追加されます。
ユーザーが発注書の変更をリクエストできるようにするには、 [ユーザーはPOの変更をリクエストできます]を選択できます(例として、下の画像を見てください)。
承認された変更をバイヤーにレビューしてもらい、サプライヤーへの変更の送信のみを許可する場合は、[ バイヤーはすべての発注書の変更を承認および承認する必要があります]を選択します。
[設定]> [会社設定]> [会社情報] ページからこれらの設定にアクセスします。
これらの設定は多くの柔軟性を可能にします。ただし、ユーザーまたは承認グループを追加して、元の承認フローに加えてすべてのPO変更をレビューすることもできます。これをインスタンスに設定する方法を説明します。
なぜ従業員が発注書の変更を要求できるようにするのですか?
すべての正直において、あなたはそうではないかもしれません。ただし、これが役立つ特定の領域があります。たとえば、年間を通してオンサイトで実施するサービスのために$ 300,000のサービスPOを開いていて、7月までにこのPOの$ 295,000を使用したとします。使用状況に基づいて、ユーザーは、POに年の残りをカバーするためにより多くのお金が必要になることを知っています。あなたのプロセスでは、追加の資金のために新しい申請書を入力する必要があります。これにより、サプライヤーに送信される新しいPOが作成されます。別のより簡単な解決策は、ユーザーが追加の資金のために元のPOに変更を要求できるようにすることです。
承認についてはどうですか?上記の例では、元の申請書は、30万ドルの承認権限を持つ人物に渡さなければなりませんでした。POを変更してさらに30万ドルを追加する場合、PO変更は60万ドルの承認権限を持つ誰かに依頼する必要があります。600,000ドルのPOに必要なすべての承認は、POの変更が承認プロセスで承認されると受信されます。
このサービス発注書は、ユーザーが変更をリクエストできるようにする場合の優れた例です。
ステップバイステップガイド
- 最初に、すべてのPO変更をレビューおよび承認する個人の承認グループを作成する必要があります。 ([設定]> [承認グループ]> [作成])この記事のために、PO変更承認者という承認グループを作成しました。
- 次に、申請書項目に カスタムチェックボックス フィールドを作成します。必ず「変更 リクエスト」という名前を付け、アクティブで編集可能にしてください。必須ではありません。次に、[ 保存して注文品目にコピー ]ボタンをクリックします。完了したら、[ 完了]をクリックします。
- 次に、発注書の「カスタム」フィールドに移動し、ページの「発注品目」領域までスクロールします。申請品目からコピーした 変更リクエスト という名前のチェックボックスが表示されます。新しいチェックボックスをクリックして、 必須に設定します。
ちょっと待ってみましょう。それで、私たちは何をしていますか?申請書では必須ではありませんが、発注書では必須のフィールドを作成しました。ユーザーは、発注書の変更を要求するまで、このボックスを選択する必要はありません。ユーザーがボックスをチェックすることを覚えていないのではないかと心配していますか?心配しないで、次のステップの後でそれがどのように機能するかをお見せします。
- 承認グループとカスタムフィールドを作成したので、申請書の承認チェーンを構築する必要があります。[設定]> [承認]> [申請チェーンの追加]を選択します。[申請チェーンの追加]をクリックした後、このグループを変更の最初の承認にする場合は、新しい承認チェーンに「 変更リクエスト」という名前を付け、[優先度]を1に設定します。元のチェーンが承認した後にレビューしてほしい場合は、優先度を50以上に設定します。
- 次に、以下の条件を設定します。
- $ 0.00を超える場合。
- 行変更リクエストが「等しい」「真」または「等しくない」「偽」の場合。
- 次に、承認グループを承認者として追加します。
- 承認者としてPO CHANGE APPROVERを追加します。
- 金額として 1.00ドルを 置く。
- ページ下部の[保存]をクリックします。
これまでのところ、承認グループ、カスタムフィールド、および承認チェーンを作成しました。それをテストして動作を確認しましょう。
- ユーザーとして、作成した申請書から作成されたPOを開き、 [変更のリクエスト] をクリックします。発注書の価格または数量を変更し、 [送信]をクリックします。
[変更リクエスト] チェックボックスをオンにしなかったため、変更を送信して次のエラーを受け取りました。
これで、ユーザーは必要なチェックボックスをオンにしないとPO変更を送信できないことがわかりました。また、チェックボックスはPO変更に対してのみ真であるため、承認チェーンが常にオフになることがわかります。
- 変更をテストして、[ 変更リクエスト ]チェックボックスをクリックします。
その他の条件
必須フィールドとして「変更リクエスト」ができたので、変更リクエストを利用可能にしたい商品のみにユーザーを制限することができます。"品目変更要求= Trueで商品が"サービス "でない送信ブロック申請承認チェーンを設定することで、従業員が事務用品などの迅速に実行されるPOに変更を要求しないようにすることができます。
重要なポイント
- 以前にユーザーに変更のリクエストを許可していない場合は、Coupaインスタンス内での変更を許可することができます。
- ビジネスプロセスに追加の承認が必要な場合、発注書変更があると、上記の手順でこの要件を達成する方法が示されます。
- この記事のコンセプトを基にして、PO変更申請プロセスを特定の商品に限定することもできます。