発注書発行の承認

サプライヤー、金額、条件を1画面で確認する発注書承認

PO承認者が承認、差し戻し、発行却下を判断できるよう、承認元、サプライヤー状況、金額、通貨、条件、納品情報、例外の根拠資料を提示します。

この例では、「承認」「差し戻し」「却下」を分けた実際の承認タスクを使います。差し戻された注文は、指定された修正が完了して再審査されるまで発行できません。

5ユーザーまで無料。クレジットカードは不要です。

コードを書かずに、項目・ワークフロー・ダッシュボードを調整できます。 1,000以上のアプリテンプレートと活用例を見る

承認テスト

実際に発行するPOを承認

承認者には簡潔な概要を提示し、必要に応じて元の資料も確認できるようにします。

  1. 01

    社内承認を確認

    PO作成前に、元の購買申請、承認済み金額、判断履歴、未完了の条件を確認します。

  2. 02

    サプライヤーの準備状況を確認します

    サプライヤーが承認されているか、または適切な責任者により文書化されたレビューまたは例外が承認されているか確認します。

  3. 03

    取引条件と納品条件を確認します

    通貨、価格、支払条件、納入条件、納入先、希望日、標準外の発注条件を確認します。

  4. 04

    承認、差し戻し、却下を記録します

    PO作成準備完了のステータスを管理するために、承認者名、日付、理由、修正担当者、結果を保存します。

実際の操作例

発行準備が整ったPOと、まだ確認が必要なPOを見分けます。

例では、作成準備中の各POに、承認元の購買申請、サプライヤー状況、取引条件、例外、発行承認の結果を紐付けています。

1組み込みのPO承認ワークフロー
4意思決定結果
3取引上の確認領域
6実務的な引き渡しレコード
承認者ビュー

判断に必要な資料を操作のそばに表示

POを発行してよいか判断するために、承認者が複数のブラウザタブを行き来する必要はありません。

根拠資料確認すべきこと考えられる結果
発注元の承認正しい購買申請、金額、発行条件購買申請レビューに戻すか、進めるか
サプライヤーのステータス承認済み、要審査、取引停止進める、保留、またはサプライヤーレビューに回す
取引条件価格、通貨、支払いおよび納入条件標準を承認するか、例外をレビューする
納入情報納入先、希望日、サービスの受入条件PO発行前に内容を確認
判断記録審査担当者、理由、日付、および次の担当者承認、差し戻し、または却下
無駄な手続きを増やさない統制

リクエスト、PO作成準備、発行承認の責任を分ける

通常の購買を過度に遅らせず、安易な自己承認を防ぐワークフローにします。

申請者が購入理由を入力

申請者は購入理由の説明と差し戻し内容の修正を担当しますが、最終的な発行承認は行いません。

購買担当者がPO作成情報を準備

購買担当者は、サプライヤー、取引条件、納品情報、正式なPOへ転記するデータを確認します。

承認者が発行可否を判断

ワークフロータスクは審査担当者だけが入力できる結果と理由を設け、差し戻し時はレコードを適切な担当者へ戻します。

システムが結果を反映

PO作成準備完了ビューには承認済みの案件だけを表示し、差し戻し・却下案件もフォローやレポート用に確認できるようにします。

この方法が適している場合

PO発行承認が対象とするのはPOの発行です。調達戦略や請求書承認とは別の判断です

関連する判断を紐付けつつ、担当責任は分けます。

PO発行前の確認を柔軟に変更したい場合に使う

サプライヤー、カテゴリ、金額、取引条件、拠点ごとのルールを画一的なパッケージ製品では表現しにくい組織に、Jodooは適しています。

購買申請の承認は前工程で完了

購買担当者がPO発行承認を申請する前に、購入理由、予算、部門、金額の承認を完了しておきます

請求書と支払いの承認は後続工程で管理

納品受け入れ、請求書照合、税金、会計、および支払い承認は、根拠資料や担当者が異なる個別の意思決定です。

テストするシナリオ

試験運用では承認ボタン以外の動作も確認

実用性を確かめるには、失敗するケースと修正後に進めるケースの両方をテストします。

標準承認済みサプライヤー

必要情報が揃い、予算内で標準条件の購買申請は、不要な手作業なしで承認まで進めるようにします。

新しいサプライヤー

サプライヤー審査が必要な場合はその条件を明示し、審査が完了するまでPOを発行できない状態にします。

金額が変更された

承認後に金額が増えた場合は以前の承認を流用せず、該当する基準額の承認をやり直します。

差し戻された取引例外

問題となる取引条件、修正担当者、期限、修正後に発行承認へ戻す経路をレコードに明記します。

コードを書かずに変更

購買プロセスを書き換えずにPOの承認を変更する

標準的な流れを維持しながら、重要な例外だけを設定で追加します。

  • 条件例外またはサプライヤーステータスの意思決定を追加する。
  • 金額またはリスクが基準を超えた場合にのみ、追加の承認者を設定します。
  • 審査担当者の編集を意思決定フィールドとコメントに制限する。
  • PO作成準備完了、差し戻し済み、却下、および期限切れの承認ビューを作成する。
よくある質問

発注書承認に関する質問

ここでは、誰が発注書を承認するか、どの根拠資料が必要か、差し戻された注文をどのように同じキューへ戻すかを説明しています。

PO発行承認ワークフローとは何ですか?

正式な発注書を発行する前の統制された承認段階です。承認済みの購買申請、サプライヤー、金額、取引条件、納品条件を確認し、判断を記録して、差し戻しや却下も処理します。

発注書は誰が承認すべきですか?

社内規程によって異なります。部門責任者、予算責任者、調達責任者、財務責任者、役員などが承認者になります。必要に応じて、POを準備する担当者と、重要な発注を承認する担当者を分けます。

PO発行承認は購買申請の承認を繰り返すべきですか?

同じ判断をそのまま繰り返すのではなく、承認元と発行条件を確認します。PO承認では、最終金額、条件、納品、例外など、サプライヤーに対する実際の発注内容を審査します。

POは修正のために差し戻しできますか?

はい。修正内容、担当者、期限を明記して差し戻し、以前の承認記録を残したまま、修正後の引き渡しを同じPO発行承認タスクへ戻します。

PO発行承認の結果をどのように保護できますか?

申請者と購買担当には担当項目の編集権限を与え、承認結果と理由は割り当てられた審査担当者だけが扱えるようにします。導入前に、各役割、差し戻し経路、修正後の再申請、最終的なPO作成準備完了の結果をテストしてください。

発行承認ワークフローを開き、判断の根拠となる資料を確認

準備済み、承認待ち、差し戻し済み、PO作成準備完了、発行済みの例を確認します。それからアプリをコピーし、実際のサプライヤー、条件、金額、審査担当者、差し戻し、および権限ルールをテストします。

PO承認ワークフローを開く