ごあいさつです。
唐突に始めた本ブログですが、今回からシリーズで提供したい「商社の基幹システムを設計しましょう！」では、
・プログラミングの練習をしたいけどネタがない！
・システムをイチから組んでみたい！
という方に向けて、
実際の企業で行われている業務フローに即して、
あくまでシステム設計の目線からネタを提供していくことを目的としています。
プログラミング技術に関しては触れず、仕様や設計を紹介し、実際のコーディングはみなさまが各自で行っていただく、
そんなスタンスでやってみます。
社内SE歴10年の私には、人に教えられるだけのプログラミング技術はありませんが、
業務知識だけはたんまりありますので、今それをここで吐き出すことにします！
さてしばらくここでテーマにしたいのは
商社
です。
・・・・
はいソコ！！いま「商社かよっ・・・」って思ったでしょ！！
「イケてるwebサイトの作り方じゃないのか、、、」ってがっくりしたでしょ！？
商社は、システムを考える上で最高の思考実験場ですぞ！！
騙されたと思ってしばらくお付き合いください。
どんなことするの？
今回はイントロなのですが、教科書的な導入よりも、あえて実践的な話を持ってきました。与信限度管理です！！
ですので基幹システムに必要なものは、全部そろっていることを前提として一旦話を進めます。
与信限度管理(または信用限度管理)とは
取引で発生する代金の大小は、代金回収に失敗した際のリスクと背中合わせです。そのために商社では、顧客に対して商品を売れる額をあらかじめ設定し、その枠内で取引するよう統制を取っています。
これを与信限度管理または信用限度管理といいます。通常は顧客に対して行いますが、場合によっては仕入先に対しても行う場合があるようです。
どうやって管理するの？
話を簡単にするため、限度額の決裁プロセスについては一旦省き、限度額が決まった状態からはじめます。決裁プロセスについてはそのうちやります(やらない)。顧客から受注(商品の購入注文)が来ました。与信チェックはどのように行うべきでしょうか？
さらに今回は単純なチェック方法として、現在の売掛金残額が今回の受注額と合わせて、与信限度額にかからなければ受注してよい、としましょう。
売掛金については今後説明しますが、ここでは「すぐに請求しない商品代金」と捉えてください。
※2
ですがこれでは、回収サイト(売掛金を回収する期限)にまだ余裕があるにも関わらず、受注ができないケースが出てきます。なので実際は、現在の売掛金と受注残額、そして売掛金の回収サイトを加味して上限に達していないかチェックするのが正しいです。与信限度管理が厳格な企業では行われますが、ここでは複雑になりますので一旦省きます。
さて、これらをシステムで実現しようとした場合はどうなるでしょうか？
与信管理に必要な機能やデータベースの項目などの観点から、どういったものが必要になるのか、一度ご自身で考えてみてください。
大まかな答えについては、次回書きます。
初回ですが思った以上に長くなりましたね、続けていけるか非常に心配w
次回もよろしくですー！
0 件のコメント:
コメントを投稿