セルフサービス調達（購買依頼・カタログ）

この章の結論

• セルフサービス調達（Self Service Procurement）は、従業員が「カタログで探す → カートに入れる → 購買依頼を提出する」ためのアプリケーションです。承認後の依頼は PO に変換されます
• カタログは、ローカル・カタログ、パンチアウト、スマートフォーム、情報カタログの 4 系統です。誰にどのカタログを見せるかは コンテンツ・ゾーン で制御します
• 依頼の既定値は「購買依頼 BU の構成（Configure Requisitioning Business Function）」と「依頼者の個人設定」から決まります
• 契約・カタログ由来の依頼は PO を自動作成しやすく、非カタログ品はバイヤーが処理する、という設計が基本です

全体像

購買依頼は、次の流れで処理されます。

1. 依頼者（Requester）または作成者（Preparer）がカタログを検索し、品目をカートに入れる
2. 明細ごとに数量・要求日・搬送先・配分（勘定・プロジェクト）を確認して提出する
3. 予算管理を使う場合は予算をチェック・引当する
4. 承認ルールに従って承認される
5. PO に変換される（自動作成、またはバイヤーによる処理）
6. 物品が届いたら受入する（依頼者が受入を記録する運用もある）

作成者と依頼者は別の人にできます（代理入力）。退職や異動で担当者が変わったときは、ジョブ Update Preparer and Requester で一括変更できます。

カタログの種類

種類	内容	主な用途
ローカル・カタログ（Local Catalog）	包括購買契約の明細や品目マスタの品目を検索できるようにしたもの	定期購入品、社内標準品
パンチアウト・カタログ（Punchout Catalog）	仕入先やマーケットプレイスのサイトで選んだ品目をカートに戻す	事務用品、IT 機器
スマートフォーム（Smart Form）	非カタログ品・サービスを依頼する定型フォーム。仕入先・価格・勘定などの既定値を持てる	役務、工事、作業依頼
情報カタログ（Informational Catalog）	発注方法の案内や外部リンクなどの情報だけを表示する	社内規程・手順の案内

カタログに関係する主な構成要素です。

• コンテンツ・ゾーン（Content Zone）：カタログ・スマートフォームなどのコンテンツを束ね、どの依頼者が使えるかを決めます。REST では contentZones リソースで扱えます
• 購買カテゴリと閲覧カテゴリ：品目の分類（カタログのカテゴリ階層）です。ショッピング画面のカテゴリ検索に使います
• 情報テンプレート（Information Template）：依頼時に追加入力させる項目のテンプレートです。品目やカテゴリに関連付けます
• 公開ショッピング・リスト（Public Shopping List）：よく買う品目を部門などで共有する一覧です

依頼の既定値

依頼の既定値は、主に次の 2 つから決まります。

1. 依頼者の個人設定：購買依頼 BU、搬送先、配分などの初期値です。初回利用時に設定します
2. 購買依頼 BU の構成：BU 共通の既定値と動作です（下表）

設定（Configure Requisitioning Business Function）	意味
Default Deliver-to Organization	明細がグローバル事業所を使う場合の搬送先組織。依頼者が使える品目マスタの範囲にも影響する
Line Type	依頼明細の既定のライン・タイプ（依頼者が変更可）
Allow one-time addresses	事前登録していない住所への配送（ワンタイム住所）を許可する
One-Time Location	非構造化のワンタイム住所を使うときに搬送先として既定する事業所
Default Procurement BU	依頼明細から調達 BU を決められないときに使う調達 BU
Price Change Tolerance	依頼から PO への価格変更の許容範囲（率・金額。両方あれば厳しい方）
Cancel Unfulfilled Demand	PO を取り消したとき依頼も取り消すか（Always／Never／Optional）
Group Requisition Import By	依頼インポート時のグループ化の基準（None・Buyer・Category・Item・Location・Supplier）
Create orders immediately after requisition import	依頼インポートの直後に Generate Orders を実行する

設定・実装の手順

1. カタログを用意する

1. 購買カテゴリとカタログのカテゴリ階層を整備する（品目をカテゴリに割り当てる）
2. 包括購買契約を作成し、ローカル・カタログで検索できるようにする
3. 非カタログ品の依頼が多い分野は、スマートフォームを作る（仕入先・価格・カテゴリ・情報テンプレートを既定）
4. パンチアウトを使う場合は、仕入先サイトとの接続を設定する（方式と設定項目はリリースにより異なるため公式ドキュメントで確認）
5. コンテンツ・ゾーンを作り、購買依頼 BU や依頼者に対して公開する範囲を決める

2. 配送先（搬送先）を決める

• 通常は、依頼者の個人設定の搬送先（Deliver-to Location）が既定値になります
• グローバル事業所を使う明細では、購買依頼 BU の Default Deliver-to Organization が搬送先組織になります
• ワンタイム住所には 2 つの方式があります。非構造化（自由入力欄に住所を書く。搬送先は One-Time Location の事業所）と、構造化（国別の項目で入力・検証する。Procurement と BU で機能を有効化した場合）です
• 社内の在庫から払い出す品目は、依頼から社内の移動（Internal Material Transfers）として処理され、PO にはなりません

3. 承認を設定する

購買依頼の承認も Approval Management のルールで経路を決めます。金額、カテゴリ、配分の勘定（原価センター）、プロジェクトなどを条件にできます。購買依頼 BU の構成には、承認に関係する次の設定があります。

• Reapproval required for changes made during an active approval process：承認者が承認中に依頼を修正したとき、再承認を必要にするか
• Approval required for buyer modified lines：バイヤーが依頼明細を修正したときに承認を必要にするか
• Enable approval override：依頼作成時に上書き承認者（Overriding Approver）を指定できるようにする

承認が回らない・止まっている場合は、トランザクション・コンソール（Transaction Console）で状況を確認します。承認の共通の仕組みは 承認ワークフロー を参照してください。

4. 依頼から PO に変換する

方法	内容	向いているケース
自動作成	承認時（または Generate Orders 実行時）に契約から PO を作る	契約・カタログ由来の定型品
バイヤーによる処理	購買オーダー作業領域の依頼明細の処理で、ドキュメント・ビルダーにまとめて PO や交渉を作る	非カタログ品、価格交渉が必要な品目
インポート経由	外部システムの依頼を Import Requisitions で取り込み、Generate Orders で PO 化	他システム（MRP・保全など）からの依頼

自動作成の条件（承認済み、カタログ品目またはインポート依頼、契約購買契約の Negotiated、仕入先と契約の特定）と契約側の設定は 購買 を参照してください。PO 化された後に依頼者が変更・取消を求めると、PO の変更オーダーとして処理されます。

5. 試験範囲で問われる個別機能

• 二重単位（Dual UOM）管理品目：一次単位と二次単位の両方で数量を管理する品目です。二次単位で価格が決まる品目の購買や、PO スケジュールでの一次・二次単位の追跡がサポートされています
• プロジェクト原価の配分：依頼・PO の配分にプロジェクト情報（プロジェクト、タスク、支出タイプなど）を持たせ、PPM に原価を連携します（プロジェクト原価）
• 単位換算：Allow Requisition-To-Agreement UOM Conversion をオンにすると、依頼と契約明細の単位が違っても契約を調達元の候補にできます
• リードタイムによる納期の算出：リードタイムを使って納期（要求日）を決める設定があります。設定場所と計算方法はリリースにより異なるため公式ドキュメントで確認してください

コード例

購買依頼は REST の purchaseRequisitions で参照できます。

購買依頼を明細ごと取得する（接続先はプレースホルダ）

curl -s -u "$FUSION_USER:$FUSION_PASSWORD" \
  "https://<your-pod>.fa.<region>.oraclecloud.com/fscmRestApi/resources/11.13.18.05/purchaseRequisitions?limit=5&expand=lines&onlyData=true"

カタログ設計は、表で整理してから設定に入ると漏れが減ります。机上演習用の設計シートの例です。

カタログ設計シート（架空の例）

コンテンツ・ゾーン   | 公開範囲               | 含めるコンテンツ
-------------------+-----------------------+------------------------------------
JP-全社標準品       | 購買依頼 BU：JP02, JP03 | ローカル（事務用品の包括購買契約）、パンチアウト（文具サイト）
JP-IT 機器          | 依頼者：情報システム部   | ローカル（PC 契約）、スマートフォーム（ソフトウェア購入）
JP-役務            | 購買依頼 BU：JP02, JP03 | スマートフォーム（保守作業・清掃）、情報カタログ（発注ルール）

実務での拡張ポイントです。

• 外部システムの依頼は FBDI（Import Requisitions）で取り込み、Create orders immediately after requisition import で PO 化までつなげる
• 属性名・子リソース名は REST API リファレンスで確認する。大量取得はページングする（REST API の基本）

落とし穴とベストプラクティス

よくあるミス

• コンテンツ・ゾーンの公開漏れ：カタログを作ってもゾーンで公開していないと、依頼者の検索結果に出ません
• 非カタログ要求の放置：自由記述の依頼が多いと、バイヤーの処理が増え、価格・仕入先の統制も効きません。頻出品目はスマートフォームか契約にします
• 価格変更許容範囲の未設定：Price Change Tolerance が空だと、依頼と PO の価格差はチェックされません
• 依頼者の個人設定：購買依頼 BU へのデータ・アクセスがないと、依頼者は依頼を作れません。ユーザー移行時にデータ・アクセスの付与を忘れないようにします

• カタログは「契約（価格）」と「コンテンツ・ゾーン（見せ方）」を分けて設計します
• 承認は依頼で済ませ、自動作成した PO の承認を省略する運用（承認のバイパス）も検討します
• 依頼者向けの教育は、ショッピング画面・カート・依頼の状況確認の 3 点に絞ります

試験対策ポイント

• 対応する出題分野：調達の模擬テスト の「Setting up Self Service Procurement」
• カタログの種類（ローカル・パンチアウト・スマートフォーム・情報）と、コンテンツ・ゾーンの役割
• 購買依頼 BU の構成の主な設定（Default Procurement BU、Price Change Tolerance、Cancel Unfulfilled Demand、ワンタイム住所）
• ワンタイム住所の非構造化と構造化の違い
• 二重単位品目、プロジェクト情報の配分、依頼と契約の単位換算

公式ドキュメント

• Introduction to the Self Service Procurement Application
• How You Configure Business Units with Requisitioning Business Functions
• How Catalogs Work Together
• How Information Templates, Items, and Categories Work Together
• Structured One-Time Delivery Address in Purchase Orders
• Project Information in Requisitions and Purchase Orders
• Import Requisitions（FBDI）

関連ページ

• 購買（購買オーダー・承認・変更）
• 調達の共通設定（調達 BU・承認・クロスピラー連携）
• P2P：購買依頼から支払・会計まで
• 承認ワークフロー（BPM・承認ルール・通知）
• セキュリティの基本（ロールベースアクセス制御）