SAP Ariba コモディティ

SAP Ariba コモディティ
コモディティは、SAP Aribaの実装において最初に設定されるマスタデータオブジェクトの1つです。購買依頼、仕入先レコード、承認ルールのいずれかを構築する前に、組織が購入するものの基礎となる分類構造が存在している必要があります。すべての依頼明細行にはコモディティコードがタグ付けされ、すべての仕入先マスタレコードは対応可能なコモディティコードに範囲設定され、承認ルール(フェーズ4)はルーティングを決定するためにコモディティと照合されることがよくあります。この記事では、すべてのAriba機能領域にわたるコモディティのコアコンセプトをマッピングし(パート1)、その後、Ariba管理者がコモディティコードと支出カテゴリを定義する際に設定するすべてのフィールドを詳述します(パート2)。
第1部: コモディティ — 中核概念(全モジュール共通)
1.1 商品とは何か

コモディティとは、組織が購入するすべてのものを標準化されたカテゴリにグループ化する分類オブジェクトであり、ソーシングの範囲設定、承認ルーティングの駆動、カタログの可視性の制限、支出分析レポートの作成に使用されます。これには2つのレイヤーがあります。コモディティコード自体(外部の標準ベースの分類値)と、支出カテゴリ(レポートおよび購買範囲の目的でコモディティコードをグループ化するAriba定義のグループ)です。ユーザーやロールとは異なり、コモディティはアクセス制御オブジェクトではなく、Ariba内のすべてのトランザクションオブジェクトおよびマスタデータオブジェクトが「これはどの種類の支出か」を判断するために参照する分類体系です。
| 項目 | 詳細 | |
|---|---|---|
| 役割 | 支出を標準化されたカテゴリに分類するマスタで、ソーシング範囲、承認ルーティング、支出レポートに使用される | |
| 使用するモジュール | すべてのAriba機能領域(購買、ガイデッドバイング、ソーシング、サプライヤ管理、請求書処理)において、すべての購買依頼明細、カタログ品目、サプライヤレコードにコモディティ割当が付与される | |
| トランザクション | 管理 > コモディティコード管理、コモディティコード/支出カテゴリのインポート・エクスポート(CSV)、支出カテゴリ設定画面 | |
| 主要テーブル | ECC/S4に直接相当するテーブルはなし — コモディティはAribaクラウドの設定オブジェクトであり、統合時にはCIGが管理する変換テーブルを介してS/4HANAの品目グループ(MATKL)にマッピングされる。共有テーブルではない | |
| S/4HANAに関する注意 | Aribaコモディティコードリストは通常、S/4HANAの品目グループと同じコードセットではない — CIGのマッピングテーブルが両者を変換する。自動同期は行われず、マッピングは統合モデル(フェーズ5)の一部として明示的に管理される |
1.2 商品コード体系

商品コード体系は、コードが属する外部(または内部)の分類基準を決定します。この選択は導入の早い段階で一度行われ、後から変更するにはコストがかかります。これは、下流のすべての仕入先割当、カタログタグ、および承認ルール条件が、選択されたコード値に対して記述されるためです。
| タイプ | コード | ユースケース | 主な動作 | |
|---|---|---|---|---|
| UNSPSC | 例: 43211500 (コンピュータ機器) | ほとんどのAriba Buying/Sourcing実装で採用されているグローバル標準 | 8桁の階層コード(セグメント > ファミリ > クラス > コモディティ);Aribaは完全なUNSPSCコードセットをプリロードして出荷し、定期的に更新可能 | |
| eClass | 例: 27-02-01-01 | 欧州標準、製造/技術調達で一般的 | UNSPSCよりも詳細な技術/エンジニアリング分類;仕入先カタログが既にeClassで分類されている場合に使用 | |
| カスタム | 例: IT-HW-001 | クライアント固有の分類オーバーレイ | 外部標準がクライアントの内部支出報告構造に適合しない場合にのみ定義;完全に手動メンテナンスが必要で、更新を継承する外部標準機関は存在しない |
設計原則: デフォルトの分類基準としてUNSPSCを採用し、標準では適切に表現できない支出セグメントにのみカスタムコードを予約する。同じ支出カテゴリ内でシステムを恣意的に混在させると、期間をまたがる支出傾向レポートが機能しなくなる。
1.3 組織レベルとデータ階層

具体的な例を用いたデータ階層
Spend Category "SC-IT" (IT Hardware)
├── Commodity Code "43211500" (Computers)
└── Commodity Code "43211600" (Peripherals)これはフラットな2階層の階層構造であり、ユーザおよびロールマスタ(フェーズ1)における「レルム/権限グループ/ロール/ユーザ」のチェーンよりもシンプルです。コモディティコードは、外部標準ベースの値です。43211500は、コンピュータを表す8桁のUNSPSCコードであり、Aribaが独自に生成したIDではなく、Aribaがそのまま採用したものです。一方、支出カテゴリは、1つ以上のコモディティコードの上位に位置するAriba定義のグループです。SC-ITは、43211500(コンピュータ)と43211600(周辺機器)の両方を単一の報告可能な「ITハードウェア」バケットにまとめ、支出分析や購買範囲の設定に使用します。この2つを混同しないでください。コモディティコードは、購入されるものを外部標準レベルで分類します。支出カテゴリは、企業が支出を報告しルーティングしたい方法に従って、それらのコードをグループ化します。
1.4 他のマスタデータオブジェクトとの統合

コモディティは単独で存在するものではありません。これは、フェーズ1~5の他の4つのオブジェクトが読み取りやフィルタリングに使用する分類キーです。
| オブジェクト | 関係性 | 実務上の注意点 | |
|---|---|---|---|
| 仕入先マスタ | 仕入先には、供給可能な品目を説明する1つ以上のコモディティコードが割り当てられる | 調達イベントの都度、仕入先とコモディティコードの割り当てを最新に保つこと — 新たに追加されたコモディティコードが割り当てられていない仕入先は、そのカテゴリのカタログ検索や優先仕入先ルーティングから黙って除外される | |
| カタログ | すべてのカタログ品目にはコモディティコードがタグ付けされ、これにより適用される購買スコープと承認ルールが決定される | 誤ったコモディティコードがタグ付けされたカタログ品目は、誤った承認経路にルーティングされ、カテゴリ固有の支出管理を完全にバイパスする可能性がある | |
| 承認ルール | 承認ルール(フェーズ4)は、多くの場合、コモディティコードまたはその親である支出カテゴリとロールを照合してルーティングを決定する | カテゴリベースのルール(例:「ITハードウェア → ITマネージャにルーティング」)は、すべての基礎となるコモディティコードが一貫して割り当てられている場合にのみ正しく機能する — タグ付けされていない品目は、意図された承認者を黙ってバイパスする | |
| 統合モデル(CIG) | CIGは、AribaコモディティコードとS/4HANA品目グループ間のマッピングを維持し、購買発注の勘定割当と仕入先マスタのコモディティスコーピングの両方に反映する | このマッピングは稼働開始前に構築すること — Aribaで作成された購買発注は、これがないとS/4HANAへの同期時に品目グループを解決できず、同期が失敗する |
パート 2: ARIBA固有のフィールド詳細
2.0 ARIBAの所有範囲

| データ区分 | ARIBAの関与 | 備考 | |
|---|---|---|---|
| 品目コードの識別と分類 | ◎ オーナー | コード値は外部標準(UNSPSC/eClass)から採用されるか、カスタムとして定義されるが、Ariba内で完全に管理される | |
| 支出カテゴリの定義と階層 | ◎ オーナー | 品目コードの上位に位置するAriba定義のグループ化。支出カテゴリ構造を規定する外部標準は存在しない | |
| 購買・承認範囲の割当 | ◎ オーナー | 購買範囲の公開、承認ルールのリンク、優先仕入先の割当は、すべてAriba内で設定・適用される | |
| 統合とシステム間マッピング | ○ S/4HANAと共有(CIG経由) | 品目グループと総勘定元帳勘定のマッピングは共同で管理される。同期ステータスとタイミングはCIG/統合モデルの設定に依存する |
凡例: ◎ = オーナー/重要、○ = 直接関与
2.1 商品コードの識別と分類

これらのフィールドは、単一のコモディティコードと、それが属する外部(または内部)の基準を識別します。これは、すべての支出カテゴリと下流の割り当てが構築される基盤です。
| フィールド | 説明 | 実務上の使用 | |
|---|---|---|---|
| コモディティコード | 分類を一意に識別する8桁のUNSPSCコード(またはeClass/カスタム相当コード) | これは外部コードとして扱い、Aribaが独自に作成したIDではない — UNSPSC値を別の意味に付け替えたり流用したりしないこと。支出セグメントが明確にマッピングできない場合は、代わりにカスタムコードを追加すること | |
| コード体系 | コードが属する分類基準(UNSPSC / eClass / カスタム)を示す | 支出カテゴリごとに1つの主要な体系に統一すること — SC-IT内で体系を混在させると、コードの粒度が基準ごとに異なるため、期間をまたいだ支出傾向の比較が信頼できなくなる | |
| コモディティ名 | コードの人間が読めるラベル(例:「コンピュータ」、「周辺機器」) | 名称は短く、ビジネス向けに保つこと — 申請者は購買依頼明細にタグ付けする際にこの名称を目にするため、技術的に詳細すぎるUNSPSCタイトルは、基になるコードを変更せずに購買UI向けに簡略化する必要がある | |
| レベル | UNSPSC階層内の位置(セグメント > ファミリ > クラス > コモディティ) | ほとんどの購買シナリオではコモディティ(最下位)レベルで分類する。セグメント/ファミリレベルは通常、支出分析の集計にのみ使用され、個別のPR/PO明細のタグ付けには使用されない | |
| 説明 | コードの対象範囲と一般的な包含/除外事項を説明する自由記述テキスト | 初期ロード時にこの項目を入力すること — これは、類似した名称のコードから選択する申請者や購買担当者にとって最良の参考情報であり、誤分類によるサポートチケットを大幅に削減できる |
2.2 支出カテゴリの定義と階層

これらのフィールドは、コモディティコードの上位に位置するAriba側のグループ化レイヤーを定義します。これは、調達部門と財務部門が支出の報告と管理に実際に使用する構造です。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| 支出カテゴリID | Ariba定義のグループ化のための一意のコード(例:SC-IT) | 支出カテゴリIDは、ソーシング/カテゴリ管理が実際に支出を報告する方法に基づいて設計します。既存のERP原価センタ階層に基づいて設計しないでください。両者が1対1で一致することはほとんどありません。 | |
| 支出カテゴリ名 | ビジネス向けのラベル(例:「ITハードウェア」) | ソーシングワークショップで得られたクライアントの既存のカテゴリ管理用語に合わせて命名します。このラベルは経営陣向け支出分析ダッシュボードに直接表示されるためです。 | |
| 親カテゴリ | 複数レベルのグループ化を使用する場合の、上位レベルの支出カテゴリへの参照 | この階層は浅く(最大2~3レベル)保ちます。深いカテゴリツリーは、購買依頼者がナビゲートしにくくなり、支出レポートの品質が向上することはほとんどありません。 | |
| 包含されるコモディティコード | この支出カテゴリに集約されるコモディティコードのセット | このマッピングは少なくとも年1回見直します。UNSPSCの更新や新しい仕入先カタログカテゴリにより、新しく追加されたコモディティコードがいずれの支出カテゴリにも割り当てられず、その支出がレポートから黙って除外される可能性があります。 | |
| レポートグループ | 支出カテゴリ階層とは独立した、経営陣向け支出ダッシュボードに使用されるオプションの二次グループ化 | 購買担当者が日常的に使用する運用上の支出カテゴリ構造とは別に、CFOレベルの集計(例:「間接費」)用に予約します。 |
2.3 購買・承認スコープ割当

これらのフィールドは、購買においてコモディティコードがどこに表示されるか、および承認ルール(フェーズ4)のルーティングにどのように反映されるかを制御します。
| フィールド | 説明 | 実務での使用例 | |
|---|---|---|---|
| デフォルト購買スコープ | この品目コードを購買依頼に使用可能にする購買/ガイデッドバイイング設定 | 新しく追加した品目コードをサイト全体に展開する前にパイロット購買スコープに制限し、誤分類された新しいコードがすべての要求元のカタログに即座に選択可能なオプションとして表示されないようにする | |
| 承認ルール連携 | 承認ルール内の照合条件として使用される品目コード(またはその親の支出カテゴリ) | カテゴリベースのルール(例:「ITハードウェア → ITマネージャにルーティング」)は、そのカテゴリ配下のすべての品目コードに一貫してタグ付けされている場合にのみ正しく機能する — タグ付けされていないカタログ品目は、意図したルーティングを黙ってバイパスする | |
| 優先仕入先割当 | この品目コードに対して優先とフラグ付けされた仕入先マスタレコードへの相互参照 | ソーシングイベント中にこれを積極的に維持する — ガイデッドバイイングは要求元を品目ごとに優先仕入先へ誘導するため、古いフラグは契約を失った仕入先に支出をリダイレクトする可能性がある | |
| 制限/ブロックフラグ | 品目コードを標準の購買依頼で使用不可としてマークする(例:契約更新保留中またはコンプライアンス保留中) | 控えめに使用し、常にその理由を説明する承認ワークフローメッセージと組み合わせる — そうしないと、要求元は単に別の誤って分類されたコードを通じて制限を迂回してしまう |
2.4 統合とクロスシステムマッピング

これらのフィールドは、コモディティコードと支出カテゴリがCIGを介してS/4HANA相当の値にどのように変換されるか、また同期の健全性がどのように追跡されるかを制御します。
| フィールド | 説明 | 実務上の使用例 | |
|---|---|---|---|
| S/4 品目グループマッピング | CIGで管理される変換テーブルであり、1つのコモディティコードを1つ以上のS/4HANA品目グループ(MATKL)値にリンクする | このマッピングテーブルは、本番稼働前に構築すること。事後対応では不十分である。これがないと、Aribaで作成された購買発注がS/4HANAに同期される際に有効な品目グループを解決できず、同期が失敗する | |
| 総勘定元帳 / 原価要素マッピング | このコモディティコードに基づく支出に関連付けられるデフォルトの総勘定元帳または原価要素。自動勘定設定に使用される | 1つのコモディティコードに対して複数の有効な総勘定元帳が存在する場合(例:会社コード別)、単一の固定値ではなく、CIGのルックアップテーブルとしてモデル化すること。そうしないと、勘定設定エラーがFIでの転記失敗として表面化する | |
| CIG同期ステータス | このコモディティコード/支出カテゴリレコードがアクティブな統合モデル(フェーズ5)の同期範囲に含まれているかどうかを示す | 新しく追加されたコモディティコードは、既存の統合モデルに自動的には含まれない。本番稼働後にコモディティコードセットを拡張した場合は、同期範囲を明示的に確認すること | |
| 最終同期タイムスタンプ | このレコードの最新の成功したCIG同期の日時 | コモディティコードの一括ロード後は、このフィールド(またはCIG監視ダッシュボード)を監視すること。一部のレコードでタイムスタンプが古いままであることは、バッチ同期が部分的に失敗したことを示す最も迅速なシグナルである |
次に読むべきもの
L1) Big Picture
| ID | Category | Title |
|---|---|---|
| ariba-001 | Overview | SAP Aribaとは何ですか? |
L2-A) Master Data
| ID | Category | Title |
|---|---|---|
| ariba-a01 | Overview | SAP Ariba マスタデータ:概要、階層、および関係性 |
| ariba-a02-01 | Master Data | SAP Ariba ユーザ |
| ariba-a02-02 | Master Data | SAP Ariba ロール |
| ariba-a03-01 | Master Data | SAP Ariba コモディティ 📍 |
| ariba-a04-02 | Master Data | SAP Ariba カタログ |
| ariba-a05-01 | Master Data | SAP Ariba 承認ルール |
| ariba-a06-01 | Master Data | SAP Ariba 統合モデル |
L2-B) Transaction
| ID | Category | Title |
|---|---|---|
| ariba-b01 | Overview | SAP Ariba トランザクション:プロセスフロー、階層、および関係 |