与信限度管理をシステムへ反映させる
今回は与信限度管理の2回目、実際にシステムへ反映させることを考えていきます。今回も詳しく説明していない機能が用意されている前提となります。 言葉の意味が分からない方は、設計範囲の広さと細かさを感じていただければ良いと思います。
必要な機能とは
私が考えたのは下記の機能です。- 取引先マスターへ与信限度額を追加
- 受注登録時に与信限度額に達していないかチェック
- 与信限度の使用状況を確認する画面もしくは一覧帳票
- 与信限度額を超過していることを知らせるアラート
ひとつひとつ見ていきましょう。
カラムの追加方法ですが、取引先マスターのサブテーブルとして作成すると、影響範囲を抑えて改修できます。 しかし与信管理は、基幹システムの根幹に関わってくるため、今後の拡張性を考えても、
可能な限りマスター本体に組み込むべきでしょう。与信に関係するシステムを作る度に、サブテーブルを結合しなければなりませんし。 このあたりはシステムの事情や予算、期限と相談です。
取引先マスターへ与信限度額を追加
与信管理を行う上で最低限増やす必要があるのは「与信限度額」の項目です。
これが元になって、与信管理が行われます。
本来は与信限度額を決める仕組み(決裁プロセスや計算式)を組み込む必要がありますが、考える範囲が広くなるためここでは省きます。カラムの追加方法ですが、取引先マスターのサブテーブルとして作成すると、影響範囲を抑えて改修できます。 しかし与信管理は、基幹システムの根幹に関わってくるため、今後の拡張性を考えても、
可能な限りマスター本体に組み込むべきでしょう。与信に関係するシステムを作る度に、サブテーブルを結合しなければなりませんし。 このあたりはシステムの事情や予算、期限と相談です。
受注登録時に与信限度額に達していないかチェック
与信管理はここでチェックできていれば、大きな事故が防げます。 つまり、限度額を超える受注を受けなければ良いのです。
その度に毎回経理や社長にお伺いを立ててるとパンクします。
ですので決裁者に承認権限を与え、決裁者が承認することで限度額を超える取引に責任を持たせます。 また超過額の大きさによって責任の大きさも変わるため、超過額によって承認する決裁者が変わるようにします。 超過額が数十万までなら課長、それ以上は部支店長、というような考え方です。
ですので与信限度チェックをする機能には、
ちょっと疲れてきましたがもう一息です！
第三者がチェックできる仕組みが必要となります。
経理の債権回収担当者が確認できるよう、画面ないし帳票を用意します。
確認に最低限必要なのは、
ただしこれでは能動的に確認しない限り、限度の使用状況を確認できません。 売掛金が限度超過していることを、アラートで発報できる仕組みもあったほうが良いでしょう。 アラートの発報タイミングは、受注登録時もしくはバッチ処理でも良いと思います。
※与信限度使用額をテーブルに保存しておくべきか
限度チェックや帳票等を使用する際に、現在の与信限度使用額を処理都度に毎回計算するのではなく、
使用状況をまとめた与信限度管理テーブルを作成しておき、そこから使用する方法もあります。
売掛金発生時、もしくは債権回収時は、必ずそのテーブルを更新します。
処理都度の集計ロジックがなくなるため、周辺処理が早くなります。
しかし余計なテーブルが増えるため管理が煩雑になったり、返品返金処理時は使用可能額を回復させる等のイレギュラー処理についても顧慮しないと、数値が正しくならない等のデメリットもあります。
個別のシステムによると思いますが、どちらが正解なんでしょうね？
ですので決裁者に承認権限を与え、決裁者が承認することで限度額を超える取引に責任を持たせます。 また超過額の大きさによって責任の大きさも変わるため、超過額によって承認する決裁者が変わるようにします。 超過額が数十万までなら課長、それ以上は部支店長、というような考え方です。
- 受注登録時に売掛金と受注額が、限度額を超過していないか確認する。
- 超過している場合、承認プロセスへ進む。していない場合受注登録をする。
- 承認プロセスには簡単なワークフローシステムが必要となる。
- 役職と超過額を対応させたマスターを呼び出した上で承認ルートの形成
- 申請
- 承認
- 却下
- 取り戻し
- 監査証跡を取るための申請内容履歴管理
ちょっと疲れてきましたがもう一息です！
与信限度の使用状況を確認する画面もしくは一覧帳票、与信限度額を超過していることを知らせるアラート
受注時の与信チェックと決裁者の承認だけでは、決裁者に対する歯止めを効かせられないため、第三者がチェックできる仕組みが必要となります。
確認に最低限必要なのは、
- 顧客の与信限度額
- 売掛金残高
- 受注総額
- 与信残高(あとどれだけ受注を受けられるか)
ただしこれでは能動的に確認しない限り、限度の使用状況を確認できません。 売掛金が限度超過していることを、アラートで発報できる仕組みもあったほうが良いでしょう。 アラートの発報タイミングは、受注登録時もしくはバッチ処理でも良いと思います。
※与信限度使用額をテーブルに保存しておくべきか
限度チェックや帳票等を使用する際に、現在の与信限度使用額を処理都度に毎回計算するのではなく、
使用状況をまとめた与信限度管理テーブルを作成しておき、そこから使用する方法もあります。
売掛金発生時、もしくは債権回収時は、必ずそのテーブルを更新します。
処理都度の集計ロジックがなくなるため、周辺処理が早くなります。
しかし余計なテーブルが増えるため管理が煩雑になったり、返品返金処理時は使用可能額を回復させる等のイレギュラー処理についても顧慮しないと、数値が正しくならない等のデメリットもあります。
個別のシステムによると思いますが、どちらが正解なんでしょうね？
まとめ
いかがでしたでしょうか？一口に限度額とのチェックと言っても、考える幅はとても広いです。今回仕様をかなり限定的にしました。
- 回収サイトを使用した顧客別月別の管理
- 受注残高も含めた管理
- 発注額と買掛金を考慮した管理(商社では商品の売り先と仕入先が同じになる場合もあります)
- 説明途中で省いた与信限度額自体を決める決裁プロセス
など、各企業の与信管理に対する考え方によって、システムはさらに複雑化します。 今回一発目に持ってきたにしてはボリュームが大きくなりましたが、 商社が単に右から左へ商品を流しているだけではないことがお分かりいただけたのではないでしょうか？ ということで今回の与信限度管理については一旦ここまで！ 次回以降は、そもそも商社の基幹システムに求められる機能を紹介していきます。 では～
0 件のコメント:
コメントを投稿