品目タイプとは｜SAPで品目の性格を決める最上位設定を実務目線で解説

一言で

品目タイプとは、SAPにおける品目が持つ性格（原材料か製品か購入品かなど）を決める最上位の分類コードです。品目タイプによって、数量管理の有無、金額管理の有無、画面表示項目などが決まります。

なぜ必要か

SAPの品目マスタは非常に多くの項目を持つため、すべての品目で同じ画面・同じ項目を扱うと現場は破綻します。たとえば原材料には「購買情報」は必要ですが「販売情報」は不要です。逆に製品には「販売情報」「原価計算」が必要ですが、外部から購入することは通常ありません。

こうした業務上の違いをシステム側で吸収するために、品目タイプが「どのビューを持てるか」「どの項目が必須か」「数量・金額管理をするか」を一括制御しています。言い換えると、品目タイプは品目マスタの項目制御と会計連携の土台です。

これを曖昧に設計すると、原価計算の対象外にすべき品目が原価ロールアップに混入したり、在庫管理不要の消耗品に棚卸の負荷がかかったりと、運用全体に影響が波及します。

代表例と比較

flowchart LR
  subgraph buy["購入される品目"]
    ROH["ROH
原材料"]
    HAWA["HAWA
商品"]
    NLAG["NLAG
非在庫品"]
  end
  subgraph make["社内で作る品目"]
    HALB["HALB
半製品"]
    FERT["★ FERT
製品"]
  end
  subgraph other["その他"]
    DIEN["DIEN
サービス"]
    UNBW["UNBW
非評価品"]
  end
  ROH --> HALB --> FERT
  HAWA -.-> FERT

  style FERT fill:#f0f6ff,color:#0053F4,stroke:#0053F4,stroke-width:2px

凡例 → 製造フロー -.-> 代替ルート ★ この記事のテーマ

標準の品目タイプ

ROH（Rohstoff：原材料／英：Raw Material）
HALB（Halbfabrikat：半製品／英：Semi-finished）
FERT（Fertigerzeugnis：完成品／英：Finished Product）
HAWA（Handelsware：商品／英：Trading Goods）：仕入れて販売する品
DIEN（Dienstleistung：サービス／英：Service）：数量・金額管理なし
NLAG（Nichtlagermaterial：非在庫品／英：Non-stock）：事務用品など都度購入
UNBW（Nichtbewertetes Material：非評価品／英：Non-valuated）：数量管理のみで金額管理なし

実務ではこの7つで大半をカバーできます。

具体例（架空の食品メーカー）

架空の食品メーカー「A社」を例に、品目タイプの設計イメージを示します。

小麦粉・砂糖などの原料 → ROH（購買ビューあり、販売ビューなし、移動平均法で評価）
製造ラインで作る生地・ソースなど → HALB（原価計算対象、製造指図で生成）
完成品のパン・菓子 → FERT（販売ビューあり、標準原価で評価）
商社から仕入れて店頭で転売するギフト品 → HAWA
社内で使う梱包資材のうち即消費するもの → NLAG（在庫を持たず直接費用化）
コンサルティング・工事役務 → DIEN

このように「同じ小麦粉でも評価方法・ビュー構成が違うべき」という判断はすべて品目タイプで吸収します。

品目タイプで決まること

数量管理の有無
金額管理の有無
勘定決定のグループ
採番タイプ（自動/外部）
必須入力項目（ビュー単位）
変更履歴の要否

技術的な位置づけ

カスタマイズテーブル：T134（品目タイプ定義）、T134M（品目タイプ×評価クラス対応）
品目マスタ（MARA）の項目 MTART に格納
トランザクション：OMS2（品目タイプのカスタマイズ）、MMAM（品目タイプ変更）
品目タイプは「ビューの表示可否」「フィールド状況」「数量/金額更新フラグ（MARC/MBEW）」を一括で制御する設計上の要です

S/4HANAでの変更点

S/4HANA自体では品目タイプの基本概念に大きな変更はありませんが、以下の点が変わっています。

品目コードの桁数が18桁から 40桁へ拡張（MATN1ではなくMATN1_EXTを使用）
Business Partner統合の影響で一部の評価クラス連携が再設計
Fiori「Manage Product Master」からの登録では一部の旧画面項目が統合
クラシカルなMM01の挙動は残っているが、Clean Core観点ではFioriアプリ経由が推奨

品目タイプのカスタマイズを増やすとアップグレード時の差分吸収コストが跳ね上がるため、標準流用を強く推奨します。

現場でよくある誤解

「品目タイプ=品目グループ」ではない。品目タイプはシステム的な性格、品目グループは分類的なグルーピング
品目タイプは品目登録時に決めた後、変更が非常に困難（MMAMトランザクションで可能だが制約多い）
新規品目タイプをコピーして作る場合、設定項目の漏れに注意

実務での決め方

業務上のフロー（購入→製造→販売）に合わせてマッピング
特殊な運用がない限り標準タイプを流用する（カスタムタイプを増やさない）
Clean Core戦略（詳細はClean Core戦略）の観点でも標準維持が推奨

トラブル事例

HAWAで受発注運用していたが製造原価計算が必要になり、HALBへの変更に苦労
サービス品目に誤ってROHを割り当て、在庫数量管理の制約で困る
非在庫品（NLAG）に在庫数量を持たせる運用をしてしまい整合性破綻

FAQ

Q. 品目タイプと品目グループの違いは？ A. 品目タイプはシステム的な性格（数量/金額管理やビュー構成）を決める制御キーで、品目グループは業務上の分類軸です。品目タイプは数十個程度に限定されるのに対し、品目グループは数百〜数千単位で定義されます。

Q. 品目タイプは後から変更できますか？ A. MMAMトランザクションで変更可能ですが、評価クラスや採番範囲が異なる品目タイプ間の変更は制約が多く、在庫ゼロ・未処理の伝票なしなどの条件を満たす必要があります。実質「作り直し」に近い作業です。

Q. カスタム品目タイプを作るべきですか？ A. 原則として標準タイプ（ROH/HALB/FERT等）を流用するのが推奨です。カスタム品目タイプを増やすと、アップグレードやClean Core戦略の足かせになります。どうしても必要な場合は、標準タイプをコピーして最小限の差分だけ変える方針が安全です。