取引先ごとにバラバラに異なる単価を処理する件
取引先（得意先）別の単価設定が複雑で困った経験はありませんか。 販売管理ソフトもいろいろですが、単価設定への対応状況はまちまち。 機能が細かくなると操作がむずかしくなり、けっきょく手書きの単価帳が手放せないとか。中小零細にも手の届く、やさしいクラウドがここに。
Contents
「単価帳」が手放せない？
売上を入力して納品書を出すっていう
基本中の基本業務なんですが、
そのために「単価帳」が手放せないっていう話が珍しくありません。
同じ会社が同じ商品を販売するっていうのに、
相手によって、また時期によって、
いく通りもの単価が存在するのが現場の実態です。
ある商品の定価（希望小売価格）を ５０，０００円 としましょう。
それを問屋が小売りに卸すのに、
「８掛け」とか「７掛け」というのはよく聞く値決めです。
８掛けだと ４０，０００円 、
７掛けだと ３５，０００円 ですね。
現場では、
他社に顧客を奪われたくない問屋と、
ちょっとでも条件のいいところから仕入れたい小売店とのあいだで
丁々発止の駆け引きがありますから、
Ａ社には ３６，５００円 で販売するが、
Ｂ社には ３５，８００円 で、
Ｃ社には ３３，４００円 で‥‥
という具合に、
いったい何掛けなんだかよくわからない、
決まった卸売価格があるようでないような状況が生まれます。
ひとつの商品にいったいいくつの価格がついているのか、
数えきれません。
ではそれに、
システムはどう対応していくか。
システムでの対応いろいろ
結論から言っておきますと、人間の頭では覚えきらないところまで覚えてくれるのがコンピュータですから、
もちろん「クラウド播磨王」は
すべての単価パターンを覚えてくれる。
＞ここ、いくらで売ってたっけ？
って
不安になって、
そのつど単価帳を開く‥‥なんて手間はいらなくなります。
そこ、
まちがいなくだいじょうぶ。
まず、
商品マスターに単価を登録するわけですが、
いちばん単純な場合、
仕入れ値（原価）がひとつ、
売価がひとつです。
経済学でいうところの「一物一価」の概念とはまったく関係ないですが、
もし会社の中で「同一の商品は同一の価格」が成立しているとすれば、
それだけで超優良会社だといえるでしょう。
では、
取引先ごとにバラバラに異なる単価体系にシステムがどのように対応しているか、
詳しく説明していきます。
商品マスターでの準備段階
システムの商品マスターには、
各商品ごとに、
いわゆる「標準原価」と「標準売価」の他に、
複数（５通りくらい）の変則単価パターンが登録できるようになっています。
取引先ごとの単価が、
先に述べた「８掛け」とか「７掛け」というように、
一定の「掛け率」で決まっているなら楽なのですが、
そうでない場合もあるでしょう。
オーディオ製品を扱っているナスティーミュージック社（仮称）は、
得意先をプラチナ、ゴールド、シルバーの３クラスにランク分けしています。
商品にもそれぞれ３通りずつの単価が設定されていて、
商品Ａ、Ｂ、Ｃの単価はそれぞれ次のとおりです。
- 商品Ａの売価
小売価格： ９，８００円
シルバー： ５，２００円
ゴールド： ４，５００円
プラチナ： ３，９００円
- 商品Ｂの単価
小売価格： ９，８００円
シルバー： ５，０００円
ゴールド： ４，６００円
プラチナ： ４，０００円
- 商品Ｃの単価
小売価格： ９，８００円
シルバー： ５，０００円
ゴールド： ４，２００円
プラチナ： ３，５００円
ありゃりゃ、
小売りではどれも同じ価格の商品なのに、
Ａ、Ｂ、Ｃで仕切値が全然ちがいますね。
どうやって単価を決めているんでしょうね。
誰もこの値決めに法則性を見つけることはできないでしょう。
こういう場合は、
各商品ごとに、
これら３ランクの単価をそれぞれ登録しておけばＯＫです。
取引先ごとに異なる単価体系への対応・その１
どの得意先に、どんな単価で商品を販売するかは、
取引先マスターで対応します。
各得意先ごとに単価情報を設定するのです。
例えば、
リンゴ社とミカン社という２つの会社があったとして、
リンゴ社には標準売価（希望小売価格）の５５％、
ミカン社には５０％で卸すことになっているとすると、
得意先マスターに登録されたリンゴ社のデータで、
「掛け率」という欄がありますので、
そこに「５５」を設定しておきます。
そうするとシステムは、
売上データが入力されるときに
「あ、この商品の単価は標準売価の５５％だ」
と
わかりますから、
ちゃんと単価欄にその単価を出してきてくれるわけです。
ミカン社のデータに「掛け率」として「５０」をセットしておきますと、
小売価格９８００円の商品Ａをミカン社に販売するときには、
ちゃんと４９００円という単価を呼び出してきてくれます。
だから、
納品書の単価がまちがえる心配が「減る」わけですね。
（ここで「なくなる」と書けないのは、
マスターの登録がまちがえることもあるからですね。）
取引先ごとに異なる単価体系への対応・その２
さっきのは「掛け率」で単価が決まる例でしたが、
上述したナスティーミュージック社のように、
「掛け率」ではなくて、
商品ごとにランク分けをして適当な単価を割り振っている場合もあります。
その場合、
ランクごとに決められた単価をあらかじめ商品マスターに登録しておく必要があります。
そして、
どの得意先がどのランクに属するか、
つまり、
どのランクの単価を使用するかを取引先マスターの「価格区分」として登録しておきます。
プラチナは１、ゴールドは２、シルバーは３としましょう。
会社によっては４つ以上のランク分けがあるかもしれません。
たとえば、
ナスティーミュージック社の取引先で、
ゴールドに分類されているミュンヘンレゲエ社（仮称）という商社があります。
この商社の登録情報として、
得意先マスターの「価格区分」欄に「２」と登録しておきます。
そうするとシステムは、
売上データが入力されるときに
「あ、この商品の単価は標準売価の７５％だ」
と
わかりますから、
ちゃんと単価欄にその単価を出してきてくれるわけです。
取引先ごとに異なる単価体系への対応・その３
さっきも出てきましたが、
ナスティーミュージック社と取引のあるミュンヘンレゲエ社は、
現在ゴールドクラスに分類されている中堅の商社です。
近年、
業績好調で取引実績もぐんぐん伸びてきました。
そこで、
ナスティーミュージック社の役員会で、
プラチナクラスへの格上げが検討されたのですが、
一部役員の慎重論もあり、
経過的措置として「ゴールドクラス単価の９０％を当面の仕切値とする」
と
決定されました。
つまり──
- 商品Ａの売価
シルバー： ５，２００円
ゴールド： ４，５００円
プラチナ： ３，９００円
ミュンヘンレゲエ社への仕切： ４５００×９０％＝４，０５０円
- 商品Ｂの単価
シルバー： ５，０００円
ゴールド： ４，６００円
プラチナ： ４，０００円
ミュンヘンレゲエ社への仕切： ４６００×９０％＝４，１４０円
- 商品Ｃの単価
シルバー： ５，０００円
ゴールド： ４，２００円
プラチナ： ３，５００円
ミュンヘンレゲエ社への仕切： ４２００×９０％＝３，７８０円
の
ようにするってことです。
おわかりいただけますかね？
こんなふうに、
ミュンヘンレゲエ社だけに対する特別単価が設定されたわけなんです。
こんな「例外」が、
わりと安直に
行きあたりばったりで次々と作られる
‥‥っていうのが中小企業の日常茶飯事ですよね。
（ま、別に中小企業じゃなくても状況は似たり寄ったりかもしれませんけど、
わたしは中小企業のことしか知りませんので、ね。）
さて、
こういう単価設定の場合ですと、
例外とはいえ、ちゃんとしたルールが決まっていますので、
取引先マスターに登録されたミュンヘンレゲエ社のデータをちょこっと修正するだけでＯＫです。
「掛け率」を「９０」に変更するだけ。
「価格区分」はこれまでどおり「２」としておけば、
システムは、
「ゴールドクラスの単価の９０％だ」とわかります。
それだけでＯＫ。
取引先ごとに異なる単価体系への対応・その４
ここまでのところで、
- 「掛け率」による単価設定
- 「価格区分」による単価設定
- 「掛け率」と「価格区分」の併用による単価設定
を
見てきました。
それでもまだ足りません。
とにかく価格競争っていうのは厳しいもんですから、
「ここまで下げないと買わない」と言われてしまいますと、
それじゃあ採算割れだとわかっていても、
取引の継続が最優先で言われるがままに切り下げなければならないこともあります。
「掛け率」がいくらだ「価格区分」がどうだとは言ってられない。
‥‥というわけで、
取引先によっては例外中の例外、
個別に単価帳に記録しておくしかしかたがない状況が生まれるわけです。
そしてそのしわ寄せは間接部門のスタッフさんにやってくる‥‥
と。
商品Ａはふつうはいくらだけど、
ｘさんに売るときだけはいくら、ｙさんに売るときはいくら、
ｚさんにはいくら‥‥、
商品Ｂはｘさんとｙさんはいくらでｚさんはいくら‥‥、
商品Ｃは‥‥
と、 まぁ極端に言えば
商品の数 × 顧客の数
通り っていうくらいの単価を記録する必要があることにもなります。
しつこいようですが、
「クラウド播磨王」はそこらへんまでちゃんと覚えてくれまから、
ま、
手間も心配もいらんわけですけども、
王さまの最後の手段はといえば、
得意先別個別単価登録ですね。
法則性も何もない、
その場しのぎのデタラメな単価設定であっても、
登録さえしとけば売上データを入力するときにちゃんと正しい単価をセットしてくれる
っていう機能です。
はじめに得意先を選んで、
次々と商品アイテムを選んで単価を入れていくだけなので、
設定方法はいたって簡単。
導入時には単価帳（たいていはベタなアナログ）のデータを、
片っ端から入力しないといけませんので、
やり方は簡単でも体力的にかなりの負担になるかもしれませんが、
いちど入れてしまえばあとは天国です。
がんばりましょう。
単価設定まとめ
──以上、取引先ごとに異なるワガママな単価設定への対応を見てきました。
こんなふうに単価は、
どの得意先に何を売るかで決まります。
（実はまだこれに「いつ」売るかという要素も加わるのですが、
それはここでは割愛します。）
あ、
そういえば、
請求先はいっしょでも、
納品先がちがったら単価が変わるというパターンなんかもありますね。
単価が決まっても、
それが「税込」なのか「税別」なのか、
ちゃんと区別できてないといけません。
だから売上データというのは、
請求先、納品先、商品の順序で入力していって、
そこではじめて単価や税区分が決まることになるわけです。
端末とサーバのあいだでは、
すごくいろんな情報のやりとりが起こっているんですね～ε=(￣｡￣;)