SAPの無償品の扱いについて(SAP 販売管理)

この記事ではSAP販売管理(SDモジュール)の無償品の考え方をご紹介しています

無償品は文字通り0円の商品のことだが、オマケとして無料になるもののこと。条件によって考え方が違う

包括的無償品(Inclusive Bonus Quantities　内増しボーナス数量)
→卵10個買ったらうち1個は無料(9個の値段で10個買える)

排他的無償品(Exclusive Bonus Quantities　外増しボーナス数量)
→卵10個買ったら1個無料でオマケ！(10個の値段で11個買える)
→卵10個買ったら無料でヒヨコが1個ついてくる(テキストに載ってた例)


販売伝票での扱いは二つとも同じで、元となる条件のサブアイテムとして登録される。有償品がTANで、サブアイテム(無償品)がTANNになる。

包括的無償品は、もう1つ別のやり方があって、TANとTANNに分けずに、全部TANとして1つのアイテムとして記載することができる。
(条件タブで見ると、無料になったアイテムの分だけ値引きされる)

文書量が減ったり、全アイテム同じ操作(ピッキングとか在庫引き当てとか)ができたり、顧客が「10個買ったのに明細に9と1と書いてあって分かりづらい」と文句言うこともない。

ただ、欠点としては、入力時や集計時に「いくつ無料だったのか」わかりづらくなる。

ともかく、こういった扱いの変更は、マスターレコードの無償品の中にフラグを立てる箇所がある。

この無償品をどうやって配達するかについて。
カラ・A・B・C・Eのオプションの中からえらべる。
(有償品が一部配送されたら発送する、有償品が全部配送されたら発送する、等)


sponsored link


Free Goods(無償品)はMaster DataのCondition(条件)で作る。
Free GoodsのT-CodeはVBN1、選択肢Document Typeの中からNA00(Free Goods)を選ぶ。

設定がけっこうトリッキー。20個以上この製品を買ったら、購入した個数の10%は無料にします、という条件だと、以下のように設定する。

1:Min. Qty(最低購入数)：20
2:From　(割合？)：10　(単位はPC=個)
3:Are Free goods(以下は無償品)：1　(単位はPC=個)
4:→in %  (2と3から自動で計算される)
5:CalT(Calcuration Type):1(Pro Rata･･･料率)
6:Free Goods:1(包括的なら1、排他的なら2)←ボタンで切り替え済

この品目を10個(最低購入数の20を下回る)にすると、割引されないのではなくて、「買えない」。最低購入数なので。

排他にするときもやっぱり複雑で、
20個買うと、1個別の商品を無償でオマケします、という場合の設定は以下のとおり。

まず、黄色で囲んだボタンを押して、Inclusive(包括)か排他(Exclusive)に切り替える。画面は排他に切り替え終えた状態。テーブルのカラムが微妙に切り替わる。(商品名や会社名はすべてトレーニング用のものです)

まず、製品名を入れて
1:Min. Qty(最低購入数)：20
2:For　：20　(xx個買ったら、の条件になる部分)
3:Add FG(Free Goods)：1　(○個オマケ。単位はPC=個)
4:→in %  (2と3から自動で計算される。割引率)
5:CalT(Calcuration Type):1(Pro Rata･･･料率)
6:Free Goods:1(包括的なら1、排他的なら2)
7:AddMat FrGd(Additional Material Free Goods):こいつが無償品になる


sponsored link

SAPの色々な略号について

この記事ではSAPのモジュールの略号についてご紹介しています

色々略称が多くてよくわからないので整理する。

SDとは、Sales and Distribution、販売管理のこと
BIとはBusiness Interigens
MMはMaterial Management
LEはLogistic Execution

以下はモジュールというより業務関連の用語か。

BTMとはBusiness Task Managementのこと
PTMとはProcure To Payのこと
OTCとはOrder To Cashのこと
CTCとはContract To Cashのこと
QMとはQuality Management、品質管理のこと
RTRとはRecord To Reportのこと
PIとはProcess Integrationのこと
OCMとはOrganizational Change Managementのこと

sponsored link

他にも
RTPとはReal Time Pricing
EH&SはEnvironmental Health and Safetyモジュール
RICEFWはReports, Interfaces, Conversions, Extensions, Forms and Workflowの略で、SAPで開発するもの全てを指す。

ほかにも何かあったら追加する。

sponsored link

SAP 販売管理、品目提案(Material Determination)で学んだこと

この記事ではSAP の販売管理(SD)で私が学んだ品目提案についてご紹介しています

品目提案：Material Determination　(品目決定という日本語訳ではない。)

同じ商品でも、見た目が違うものというものがある。例えば12月の間はクリスマスバージョンのパッケージを販売するとか、夏の間はキャンペーンの応募用紙がついたパッケージを販売するとか。そういうのをコントロールする。
これを制御するのが、Determining materials(品目変換)という機能。
入力した製品に対し、Substitute material(代替品目)を指定してくれる。


他にも、「このお客は商品Aしか受け取らない」というのを定義したり(特定のチェーン店向けのデザインとかかな)もできる。

Automatic Product Selection(自動商品決定?)という機能では、期間によってどの代替品を使うか決めたり、複数ある代替品のどれを優先的に使うか、などの設定ができる。

品目提案は、コンディションテクニック(Condition Technique)こと条件テクニックで定義された順番で品目を決めていく。日付などの情報をもとに、順に関連テーブルにアクセスしていって、最後に品目を決める。

Material Listing(品目制限)は、特定の商品を受け付けないようなお客を登録しておく。(お菓子メーカーがセブンイレブンにローソン向けのパッケージを出荷したら問題とか、そういう感じか)


クロスセリングは、1点購入したお客に対して、関連商品を勧めること。クロスセリングの設定を行っていると実施できるらしい。

動的品目提案という言葉も覚えておくころ。



sponsored link


実装する際の手順など

Material Determination(品目提案)は、マテリアルマスターではなくて、Material Determinationというマスタに登録することになる。T-CodeはVB11(Create)

1商品につき1つの代替品しか登録できないように見えるが、1つの品目に複数の代替品目を設定することもできる。その場合は、とりあえず1つの代替品を入力した上でAlternative Materialsボタンを押せば、1つの品目に2つ以上の代替品を設定できる。

Listing/Exclusion(品目制限)も同様にMaster Dataで行う。品目提案の並びに「Listing/Exclusion」
T-CodeはVB01
リスト制限はA001、除外はB001。掲載しているもののみOKなのがリスト制限で、禁止リストが除外。





sponsored link

SAP SDで学んだリベートについて

この記事ではSAP SDのリベート機能についてご紹介しています

リベートというのは、一定期間の売り上げに対して、払い戻しをする仕組みのことらしい。例えば11月に小売店が100万円分のケータイを売ったら、小売に納品した携帯メーカーが5万円キャッシュバックしてくれる、とかそういうことの模様。「【100万円売るから】5万円割り引いて！」じゃなくて「100万円売ったから」というのがポイントなのかな。

アメリカの小売では、お客に対してメールインリベートという仕組みがあって、商品購入後しばらくしたら割引額分の小切手がメールで送られてくるなんていうことも。

ポイントは、一旦売り上げが立ったあとで、割引(出金)が発生するというところかな。

複数の請求書をまとめて、合計額がリベート条件に適合したら、値引きが実施される。

裏側で合算処理とかが毎回走るので、リベートを使わない会社であるならば、機能をオフにしておいたほうが性能劣化しなくてすむ。
XD02で販売エリアと顧客を指定して、Sales AreaデータのBilling Documentにあるリベートチェックボックスをオンにする。

さらに、F2などの請求伝票や、S. Org1000などに対して、リベート機能を有効にすべく、IMGを設定する必要がある。
SD -> Billing -> Rebate Processsing -> Activate Rebate Processingを実行し、
次に現れるSelect Billing…で伝票に対して設定
同じくActivate …　for Sales Orgで販売組織について有効にする。


これまでの価格決定が、販売文書を作るときに適用されているのに対し、今回は請求書ベースで価格決定がなされることになりそう。


SAPだとRebatesとなる。SDのMaster DataのAgreementの中に「Rebate Agreement(リベート契約)」という項目がある。T-codeはVBO1(Create)
*VB01ではなくてVBオーワン。(VB01【ゼロワン】はCreate Exclusion)


メモ：なぜかリベート契約がアクティブになっていないらしく、いくつも販売伝票を切って請求書作っても、全ての売り上げがリベートの累計に認識されていない。。。VK780というエラーメッセージが出て、リベートが有効になっていないようなことが示唆されるのだけれど。。


sponsored link


Rebate Settlementの日本語訳は今のところ不明。

Rebate Agreement(リベート契約)には、いくつか種類があって、
・得意先/品目　→　例：その顧客が今月商品Aを10万円以上買ったら1%引き
・得意先　→　例：その顧客が今月10万円以上買ったら1%引き
・得意先階層→？？

リベート条件は、Agreement関連のMaster Dataに作成していく。
個数なのか率なのかは、定義によってあらかじめ決められているので、出て来た伝票に淡々と入力する。


身近なリベートの例としては、東京のバスの割引なんかが近いかも。前売りの回数券とは違って、1ヶ月のうちにSuicaかPASMOで10回乗車すると、1回割引きする、という仕組みである。期間中の乗車回数を覚えておいて、条件を満たすと割引する、という点で似たような仕組みを使っているのかな。


sponsored link

SAP SD、クレジットメモとデビットメモの違い

この記事ではSAPの販売管理で使われるデビットメモとクレジットメモの違いについてご紹介しています


アメリカでは、請求書などにおいて支払うべきお金をCredit、アカウントにチャージされているおカネ(日本でいうプラスの残高)をDebitといいます。
クレジットカード(Credit Card)とデビットカード(Debit Card)と同じ用語なのですが、どうも混乱しがちです。

お金を勘定する際の大原則として、
・人(法人、家庭など)には必ずアカウントがある
・人が支払うべきお金(出金)はCreditとして、アカウント上に記入する
・人が支払ったお金(入金)はDebitとして、アカウント上に記入する
・ある期間で、Creditをマイナス、Debitをプラスとして計算したのがBalance
・Balanceがマイナスになっていたら、人はお金を払わないといけない
・逆にBalanceがプラスになっていたら、多少の請求(Credit)が来ても支払い不要

※単純化するために「人(消費者)」目線で書きました。

日本でいち市民として暮らしていると、請求書=すぐに支払う、という図式が成り立つので、あまりアカウントという概念を意識しなくて住みます。料金支払いは全てトランザクションで完了してしまうといったところでしょうか。

反対にアメリカは、全ての支払い先に対して個人のアカウントが設定されていて、支払いはどんどんそこにチャージされる(Creditとして計上される)ので、適宜支払いをして、Balanceがマイナスにならないようにする必要があります。トランザクションというより、B/Sで管理されているような間隔になります。

支払う人側の立場に立つと「クレジット＝うれしくない」「デビット＝うれしい」と覚えておきましょう。
sponsored link


そんな余談を挟んだ上で、定義をみると


クレジットメモ ：得意先の苦情をもとに登録される販売伝票
→クレジットメモによって財務会計の売掛金(Receivable)が減額されます。

デビットメモ ：苦情をもとに登録される販売伝票
→デビットメモによって財務会計の売掛金(Receivable)が増額されます

今までの理論と視点が逆になったので気をつけましょう。

クレジットメモは、請求者がお客に5000円の請求書を出した(売掛金5000円)けれど、過剰請求であったことが発覚して、請求書が4000円に減額されるような場合の伝票が「クレジットメモ」。お客側のクレジットが減額されるので、請求者はうれしくない。
(お客側は、この反対で、アカウントに1000円のデビットを受け取る・又は1000円のクレジット減額を受け取ることになります。)

逆にデビットメモは、請求者がお客に5000円の請求書を出した(売掛金5000円)けれど、何か忘れていて、再計算した結果、6000円に増額し、デビットメモという販売伝票を発行します。お金が多くもらえることになるので、請求者はうれしい。
(お客がわはまたこの逆で、1000円さらにクレジットが増えることになるのでうれしくないです)

ちょっと無理やりだけれど、クレジットは嬉しくない・デビットは嬉しい、ぐらいに思っておきましょう。ただし、クレジットとデビットはいつもワンセットなので、どちらの立場にいるか意識しましょう。


sponsored link

SAP SD、価格協定について学んだこと

この記事ではSAP SDの価格協定(Agreement)についてご紹介しています


Agreementsには2通りあって、Promotion(プロモーション)と、Sales Deal(販売ディール)。

SAPにおけるプロモーションと販売ディールの関係

1つのプロモーションの下に、複数の販売ディールが紐付いていて、販売ディールはいくつかの有効期間(Validity Period)が設定されている。

例えば「夏の大バーゲン」がプロモーションとすると、
夏のバーゲンは「8月限定、水着処分、男性物40％、女性物50％引き」や、「7-9月までの期間、半袖5%オフ」とか複数の販売ディールが含まれている感じか。

プロモーションは、Master Dataに作成する。T-CodeはVB31(登録)

Master Data -> Agreements -> Promotion -> Create/Change/Display

ここで作るのは名前と有効期間だけ(箱を作るイメージ)。

販売ディールはそれに紐付ける形で、同様にMaster Dataに作成する。T-CodeはVB21

Master Data -> Agreements -> Sales Deal -> Create/Change/Display

Create with referenceで、紐付けたいプロモーションを呼び出して作成する。
このときに、有効期間や、支払い条件(20日以内なら3%引き、40日以内なら2%引き、とか)を指定した上で保存する。

保存後、VB22(Change for Sales Deal)で作成した情報を呼び出し、「条件(Condition)」ボタンを押すと、割引条件などを入力できるようになる。

まず、客別なのか、客別商品別なのか、選択する。

特定のお客に対してxx月は5%引き、とやりたいならば条件タイプK007を選択して、次の詳細画面で、顧客名と割引率と期間を登録する。

特定の商品に対してxx月は10%引き、とやりたいならば条件タイプKA00を選択して、次の詳細画面で、顧客名と商品名、そして割引条件を入力していく。

なお、ここで登場しているMaster Data -> Agreementsは、このほかにも顧客商品情報(Customer Material Information)の編集ができる。


このプロモーション・販売ディールを使って販売伝票を作成(VA01)すると、その条件に応じた割引が行われる。

これは実務経験のない私なりの想像だけれど、プロモーション自体には意味が無いけれど、あとから「このプロモーションが成功したかどうか結果を抽出しよう」というようなれポーティングをする際に、プロモーションの番号でフィルタリングできるための措置だと思う。



sponsored link



最後に、販売伝票を作って出荷して請求書を作成すると、プロモーション等の情報が、伝票のアイテム詳細に表示される。

個人的には、作成した割引価格が適用されなくて、四苦八苦したが、条件入力の際に、有効期間を間違って入力してしまい、販売日が割引対象から外れていただけだった。

なお、期間限定の割引価格の対象日は、どの日付かというと、配達日ではなくて、Pricing Dataがその期間に入っているかどうかであった。

sponsored link

SAP SD、特別価格設定機能(Special Function)について学んだこと

この記事では私がSAPの販売管理のトレーニングで学んだ、特別価格設定機能ご紹介しています

SAPのSpecial Functionの日本語訳は、特別価格設定機能です。

複数の条件タイプを排他的に利用したり、個数限定の割引を行ったりするのに使う機能をまとめて特別価格設定機能と呼ぶようです。

補足条件(Condition Supplements)

条件除外(Condition Exclusion)


sponsored link

SAP SDで条件レコード、スケール率のチェックの話と、エラー(VK047)の解決策

この記事ではSAP SDで条件レコードを作ろうとする時の注意点についてご紹介しています

条件レコードを作ろうとしたら、エラーメッセージが出ました。
メッセージ番号はVK047でした。

やろうとしていたことは、重くなればなるほどに送料が増える、という条件レコードを作ろうとしていました。このエラーメッセージによれば、「一番重いときの送料である30ユーロを、前の金額である20ユーロより低くしなさい」という指示でした。
(Amount 30,00 EUR must be smaller than the preceding value 20 EUR)

だんだん値上がりしていくのに、何でそんなエラーがでるのか意味がわかりませんでしたが、これは、別の設定を間違えていたようです。

Condition Typeの設定で「降順／昇順　(Decsending / Ascending)」という項目があって、重くなるほどに料金を値上げしたいような場合は、Ascendingにしないといけないのに、なぜかDescendingになっていたためにエラーになったようです。
sponsored link


これを直すためには、Condition Typeの、Scalesの項目にある、Check valueという項目をカラにしましょう。日本語だと、スケール率のチェックというはず。
A(降順)、B(昇順)、カラ(チェックしない)の3つが選べます。

今回は、A;Descendingが入っていたため、毎回降順になっていないかチェック処理が走ってしまい、キャンセルしたくても降順になっていないとエラーがでて先に進めなくなります。金額を降順に仮置きしておけば一発でキャンセルできます。



sponsored link

SAP SDのトレーニングで疑問に思った、条件タイプKF00の設定

この記事では私が今日SAPのSDのトレーニングで学んだことをご紹介しています

Access Sequence(検索順序)やCondition Type(条件タイプ)の関係と、そこから派生するCondition Master(条件マスタ)の関係がだいぶ分かってきた。ただ、演習をしていて腑に落ちないのが、KF00(Flight:運賃)というAccess Sequenceに定義されている条件レコードが、34(Incoterms Part1+2)　33 (Incoterms)というものであったこと。大事な検索順序なのに、条件が変ではないか？
念のためもう1つの演習サーバのデータもチェックしたものの、やはりそちらも同じ設定であった。

sponsored link

SAP SDの条件レコード(Condition Record)の覚え書き

この記事では条件レコード(Condition Record)について私が理解したことをご紹介しています


SAP のSDモジュールにおけるCondition Record(条件レコード)は、どのお客がどんな条件のときに幾らで商品を販売するか、といったような情報を蓄えておくもの。Master DataのConditionから変更ができる。Master Dataの情報だけれど、少しトリッキーで、IMGに似たメンテナンスを行う。

この「販売エリアで、このお客に対して設定されている条件レコードの一覧を表示させる」といったこともできる。この機能は価格設定レポート(Pricing Report)という。

表示させる単位は
　・ページヘッダー
　・グループヘッダー
　・品目
に分けられており、共通項をページヘッダにまとめたりすることでサマることができる。
(DBでいう正規化:normalizationみたいなものか？)

Condition RecordにText(文章)を入れておくと、コピーできる。
契約条件とかを書いておけば、価格設定された時に、何故その価格になったのかの説明などが自動的にコピーされるので便利、という機能なのかな。
sponsored link


sponsored link

SAPの販売管理で、価格設定をするまでの関連カスタマイズ画面

この記事ではSAP SDで、価格を決めるまでに必要な設定画面について述べています。


condition table　(条件テーブル)　条件レコードのキー項目を定義したもの。3桁の数字で名前がついている(例；304)

Condition type　（条件タイプ）　価格を決定するための計算方式。個数に応じて割引、とか一定以上の重さになったら割増、とかそういう条件。PR00とかK007とか、たいてい4桁の英字数字組み合わせ。


Access sequence　（検索順序）　正しい条件にするために、どういう順番で検索するかを規定している。条件テーブルをどういう順番で使うかが定義してあり、Condition Type同様に4桁である。PR02とか。

Pricing procedure　（価格決定表）　最終的に価格を決定するために、どういう条件タイプを使うか定義してある。RVAA01のように6桁の英数字である。


※この順番でカスタマイズしていく。（とあるし、カスタマイズ画面の順番もそのとおりなのだけど、実際は検索順序を定義してからでないと条件タイプが定義できないような気がする。。。)

あと、Condition record　（条件レコード）というのは、価格決定に使われるデータのこと。重さ、とか、地域、とか。

sponsored link

Condition table　(条件テーブル)　条件レコードのキー項目を定義したもの

1つの条件テーブルにどんな条件が必要なのか、左側のフィールドにポコポコと追加していく。(なお、条件レコードの右側の一覧は、PgDnキーを使わないとスクロールできないので要注意）

Condition type　（条件タイプ）　

PR00とか、価格決定に必要な条件。

詳細画面になると、どのアクセスシークエンス(検索順序)が使われるか、とか手で金額を変更していいか、とか、割引なのか割増なのか、など設定する項目がたくさんある。

Access sequence　（検索順序）

SAPお得意のすごいややこしい設定。設定変更したいレコードを右側の画面から選んだら、左側のツリー構造のフォルダをダブルクリックすると、選択したレコードの変更(詳細)画面に遷移する。

これが、詳細画面。検索順序がどうなっているのか、詳細が分かる。この画面でみると、4つの項目からなっている。1つ1つの項目は先ほど設定した3桁の数字からなる「条件テーブル」である。

なお、条件テーブル選択して、右側のFieldフォルダをダブルクリックすると、その条件テーブルに何が含まれているか(何がインプット・アウトプットなのか)がグラフィカルに表示される。

Pricing procedure　（価格決定表）

価格決定表もこの画面で詳細を閲覧できる。

価格決定に至るまでに、どんな条件レコード(PR00とか、個数割引とか、顧客割引とか)が使われるかをひたすら定義している。

条件タイプや条件テーブル、価格決定表などの包含関係は以下のとおりです。

これに、顧客価格決定表というキー(アルファベット1文字)を決めて、販売エリアとそのキーをもとに、価格決定表を定義して、顧客マスタから販売エリアと顧客価格決定表をもとに、価格決定表を呼び出す。(ここがいまいち理解できていない)

オマケ
英語ネイティブでもちゃんと図が書けるんだ！
http://wiki.scn.sap.com/wiki/display/SD/SD+Pricing+overview

sponsored link

今日SAP SDで学んだこと(2014/01/07)

この記事では今日私がSAP SDのトレーニングで学んだことをご紹介しています

1.FYの更新

毎月、MMPVメニューで、月締めと新しい月をオープンさせるのと似た要領で、会計年度も閉じたり開いたりしないと、新しい年の業務ができない。

Goods Issueをしようとするとエラーが出る。

色々対応してできるようになったが、真偽のほどは確認中。OMBTとOB52のメニューを使った。



sponsored link

2. 価格の設定(Pricing Configuration)

用語の確認
Condition table　(条件テーブル)　条件レコードのキー項目を定義したもの。3桁の数字で名前がついている(例；304)。

Condition type　（条件タイプ）　価格を決定するための計算方式。個数に応じて割引、とか一定以上の重さになったら割増、とかそういう条件。PR00とかK007とか、たいてい4桁の英字数字組み合わせ。


Access sequence　（検索順序）　正しい条件にするために、どういう順番で検索するかを規定している。条件テーブルをどういう順番で使うかが定義してあり、Condition Type同様に4桁である。PR02とか。

Pricing procedure　（価格決定表）　最終的に価格を決定するために、どういう条件タイプを使うか定義してある。RVAA01のように6桁の英数字である。


※この順番でカスタマイズしていく。

あと、Condition record　（条件レコード）というのは、価格決定に使われるデータのこと。重さ、とか、地域、とか。

なお、価格を決定するためのプロセスについてはこのブログがすごく分かりやすい。具体例満載である。
http://www.tamashima.biz/archives/2011/11/sap_32.html

複数の条件を決めて、料金が決まっていく流れを意識すること。
定価はあるものの、このお客でこういう条件(現金とか)なら幾らで売ります、という流れがあるはず。

だから、SAPの販売管理では、顧客マスタを作って、商品マスタを作ってそこに価格を登録して、、という小学生みたいなことはしなくて、顧客マスタを作って、価格条件を作ったら、その組み合わせで、商品マスタ(価格の情報)を入れられるようにしてある。だから、顧客情報と販売エリアを指定しないと製品マスタがいじれないようになっているのか。

あと、テキストというナゾの項目があったけど、EDIに使う情報とか、とにかく後々保有していて欲しい情報を書いたりするらしい。


sponsored link

今日SAP SDで学んだこと(2014/01/06)：価格条件(Price Condition)

この記事では今日私がSAP SDのトレーニングで学んだ価格条件の概要について書いています。


期間、個数、金額などを指定して、割引(値上げ)を行えるように設定できる。(品目マスターデータに設定する)
最低購入数等も設定できる。

5個以上買ったら割引(4個未満の購入は割引なし)、というのと、10個以上から割り引くしそもそも5個未満では買えない、というのも同じ設定で行うなのかな？

Price conditionが定義されていないと、その製品を売っても価格が0になってしまう。
SD -> Master Data -> Conditions -> Select Using Condition Type
(T-CodeはVK11で登録、VK12で変更、VK13で参照)

Key combinationでMaterial With release statusを選択すること。

Special Discountなどを適用する場合は、Customer/material with release statusを選択する。

Price Condition record (PR00)だと、顧客と商品を指定し、指定した商品の購入個数に応じて割引を行える。

Customer Discount Condition(K007)だと、顧客に対して購入額に応じた割引を行える。
なお、見方は次のとおり

100EUR以上、1000EUR未満だと2%(2,000-)の割引
1000EUR以上、5000EUR未満だと3%(3,000-)の割引
5000EUR以上だと、5%(5,000-)の割引


sponsored link

K007やPR00といったCondition Typeがなぜ「個数」とか「割合」で定義されているかというと、IMGでそう定義されているから。

あと、複合技(○個買ったら幾らで、幾ら超えたら何割引きで・・・)で混乱しそうになるけれど、Pricing Prosedureによって、どの条件をどういう順番で使うか定義してあるので、それに従って計算すれば良い。(後述するはず)

IMG -> Sales and Distribution -> Basic Function -> Pricing -> Pricing Control -> Define Condition Types : Maintain Condition Types
で定義されている。

A: Percentageや、B:Value scaleといった定義がある。
他にも変えられるのは、
・値のプラスマイナス(マイナス：Negativeにしておくと、パーセンテージ入れると何%引きとかにできる)
・有効期間のデフォルト値
・計算の単位(量なの、額なの、重さなの？)


日本語に訳すと
Condition Teqnique：条件テクニック
Condition Type：条件タイプ
Condition Table：条件テーブル
Acess Sequence：検索順序？
Pricing Prosedure：価格決定表




sponsored link

SAP SD、条件タイプのヘッダー・品目レベルの違いについて

この記事では今日私がSAP SDのトレーニングで学んだ「条件タイプ」のヘッダーレベル・品目レベルの扱いについてご紹介しています


 条件タイプ：Condition Type

Header Conditionは、ヘッダーレベルで適用される条件。
例えば10%オフならば、まずヘッダーレベルで10％ひいて、内訳を個別の商品に分散させる。
対義語はアイテムレベルの条件で、ヘッダー情報を見ても条件が表示されない。

それぞれ、IMGのCondition Typeで設定できて、
□Header Condition
□Item Condition
というチェックボックスになっている。

sponsored link



2つのアイテムがあって、ITEM10が100ドル、ITEM20が50ドルで、
「15ドルの割引をする」という条件を作るとする。

HeaderとItemの両方にチェックを入れないと、たぶん割引はされない。(そんな条件を作っても意味が無いけれど)

HeaderとItem両方にチェックを入れると、双方のアイテムから15ドル引くので、総計30ドル引き

Headerだけにチェックを入れると、全体から15ドル引いて、各アイテムに按分するので、10ドル引き&5ドル引きとかになる。

Itemだけにチェックを入れると、たぶんそれぞれ15ドル引きして、結果はHeaderには出てこない。(たまたま結果は1個目と一緒になるけど)


たぶんと書いたのは、条件タイプの設定によっては、設定してある検索順序(Access sequence)と矛盾を起こすので、設定できないため。

あと、全体の総重量に対して費用が発生する、とか、総金額の何パーセント引きとか、条件タイプにも色々な種類があったり、グループ条件とかも絡んでくるので、物事はそこまでシンプルにはできない。


Exclusive(排他)にチェックを入れる(X)と、他の条件が無視される。
無視されたかどうかを確認するには、Analysisボタンを押すと、どの条件タイプが使われて、どれが無視されたかを一覧で表示してくれる。Exclusiveによって排他されると、Condition ignoredというメッセージが表示される。



sponsored link