条件タイプとは｜SAPの価格・割引・税を表す計算要素を実務目線で解説

一言で

条件タイプとは、SAPにおける基本価格・割引・運賃・税など「金額計算の1要素」を表す4桁の識別コードです。PR00（基本価格）・K007（得意先割引）・MWST（税）など、計算上の1行分を表現します。

なぜ条件タイプが必要か

販売価格は複数の要素から構成されます。「基本価格」「数量割引」「得意先割引」「運賃」「税」をそれぞれ別の計算単位として扱わないと、値引の履歴や税計算の根拠が追えなくなります。

条件タイプがないと、次のことができません。

「基本価格はいくらで、そこから何%引いて、税はいくらか」を明細で追えない
条件ごとに有効期限・スケール（数量別単価）・通貨を個別に設定できない
割引の種類（%値引 vs 定額値引）を区別できない
監査時に「なぜこの金額になったか」を説明できない

逆に条件タイプを適切に設計すれば、複雑な価格ルールも透明性をもって運用できます。

価格設定手順の中での位置づけ

flowchart LR
  PP[価格設定手順
RVAA01] --> CT[条件タイプ
PR00]
  CT --> AS[アクセスシーケンス
PR02]
  AS --> CTB1[条件テーブル
得意先/品目]
  AS --> CTB2[条件テーブル
品目]
  CTB1 --> CR[条件レコード
VK11で登録]
  CTB2 --> CR
  CR --> VAL[実価格
1,000円/EA]
  style CT fill:#f0f6ff,stroke:#0053F4,stroke-width:2px,color:#0053F4

凡例 → 参照関係 VK11 = 条件レコード登録Tコード ★ この記事のテーマ

条件タイプは「アクセスシーケンス」を通じて「条件テーブル」を参照し、実際の価格は「条件レコード」に格納されます。

具体例：代表的な条件タイプ

SD標準で提供される主要な条件タイプは次の通りです。

条件タイプ	内容	計算区分
PR00	基本価格（Price）	価格
K004	品目別割引（定額）	割引
K005	得意先×品目割引	割引
K007	得意先割引（%）	割引
KF00	運賃	加算
MWST	出力税（消費税）	税
BO01	グループリベート	リベート（ECCまで）

架空のA社で「得意先Bに品目Xを100個販売」する場合、PR00で1,000円/EA、K007で3%引、MWSTで10%課税、という形で各条件タイプが個別に計算され、最終金額が算出されます。

技術的な位置づけ

SD・MM共通の「条件技法（Condition Technique）」の中核要素
出力制御・テキスト決定・勘定決定などにも同じ仕組みが応用される
条件タイプごとに「計算区分」「符号（+/−）」「必須/任意」「統計」などの属性を設定
アクセスシーケンスで「どの粒度で値段を引きに行くか」を定義

カスタマイズパス（IMG：Implementation Guide、SAPの設定ガイド）

SPRO > 販売管理 > 基本機能 > 価格設定 > 価格設定制御 > 条件タイプの定義（V/06）
SPRO > 販売管理 > 基本機能 > 価格設定 > 価格設定制御 > アクセスシーケンスの定義（V/07）
SPRO > 販売管理 > 基本機能 > 価格設定 > 価格設定制御 > 条件テーブルの定義（V/03）

主要テーブル

テーブル	内容
T685	条件タイプマスタ
T682 / T682I	アクセスシーケンス
KONH	条件レコードヘッダ
KONP	条件レコード明細
A###	条件テーブル（番号は動的）

S/4HANAでの変更点

条件タイプ・アクセスシーケンス・条件レコードの仕組みは従来通り維持
SAP Fiori App「販売価格の管理」で条件レコードをWeb UIから保守可能
ECCで使われていたSD Rebate（BO01等）はS/4HANAで廃止予定→Condition Contract Management（CCM）へ移行
HANAのインメモリにより、条件検索の高速化と大量価格マスタの運用が現実的に

現場でよくある誤解

「条件タイプ=価格マスタ」ではない。条件タイプは「計算要素の定義」で、価格そのものは条件レコードに入る
PR00を複数並べると最初の1つしか有効にならない（同一条件タイプの多重適用は通常不可）
統計フラグを立てた条件は金額計算に影響せず表示のみになる
アクセスシーケンスを設定しない条件タイプは、手動入力専用になる

実務での決め方

条件タイプを新規に作る・標準を流用するかの判断基準は次の通りです。

標準条件タイプ（PR00/K007等）で業務要件を満たせるか？ → Yesなら流用
計算ロジックが特殊（例：特定の式で計算）→ Yesなら独自条件タイプ（Z始まり）
アクセスシーケンスの粒度が標準と違うか？ → Yesなら独自
レポートで個別に集計したいか？ → 別条件タイプに分けると集計しやすい

安易にZ条件タイプを増やすと価格設定手順が肥大化し、保守コストが跳ね上がります。まずは標準のカスタマイズで対応できないか検討するのが鉄則です。

トラブル事例

アクセスシーケンスの順序ミスで、優先すべき得意先別価格ではなく標準価格が適用されて過剰値引
条件レコードの有効期限切れに気づかず、価格がゼロで受注→出荷→ゼロ円請求
符号（+/−）の設定ミスで、割引条件が加算になり金額が倍に
通貨設定ミスでUSD建ての価格がJPYで計算されて100分の1に

FAQ

Q. 条件タイプと条件レコードの違いは？
条件タイプは「PR00=基本価格」という計算要素の定義、条件レコードは「品目Xは1,000円/EA」という実際の値です。条件タイプは設定（カスタマイズ）、条件レコードはマスタデータ（運用中に日々登録）という関係です。

Q. 新しい割引体系を追加したいのですが、どうすればいいですか？
まず標準条件タイプ（K004/K005/K007等）で対応できないか確認してください。できなければZ条件タイプを新規作成し、アクセスシーケンスと条件テーブルを設計し、価格設定手順に組み込みます。Z作成はコンサル領域の作業です。

Q. 条件タイプの「統計」フラグは何のためにありますか？
金額計算には含めないが、レポート用に表示だけしたい情報（例：想定利益、参考原価）に使います。統計フラグを立てた条件は合計額に影響しません。