与信管理 のバックアップ(No.1)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- 与信管理 へ行く。
- 1 (2014-06-26 (木) 11:03:47)
- 2 (2016-03-24 (木) 18:19:59)
顧客の信用管理のことで、英語ではCredit Limit Managementと表記する。
概要 †
商いとは、財やサービスを提供し、その対価を得る活動の総称であるが、その「対価を得る」が具体的に指すもの、即ちちゃんと金払ってくれんのか？とかおたくの規模で、こんな取引できんの？といった客先の信用を管理しましょう、というのがコンセプト。
なお、貿易取引における特定取引先と商いをするとかしないとか系の話は、リスク管理やコンプライアンス管理といったところで触れるべき内容であるため、ここでは冒頭の通りCredit Limitに関するテーマのみを対象とする。
与信管理規定について †
まっとうな企業であれば、ちゃんとした管理規定があるもの。
システムの利用も含めて申請→承認を如何に実施するか、肩書きごとに持つ裁量の金額、金額ごとに通らなければならない承認者のロールなどが明確になっている必要がある。
また、ロジからについては、受注額を加味するのか否か、与信のブロックタイミングは受注止めなのか出荷止めなのか、与信ブロックを解除できる権限は誰に付与するのか・・・といった大方針は、これが拠りどころとなる。
業務的な話 †
超ざっくりプロセスを規定すると、顧客管理と取引管理の二つに分かれる。
顧客管理 †
こちらは取引先の素性の審査や枠の設定についての話で、大きくは、新規取引における審査と設定、継続取引先の与信枠見直しがある。
前者は、日本であれば東京商工リサーチや帝国データバンクの情報および有価証券報告書など、海外であれば保険会社がそういう情報を公開しているのでそれをreferenceしたりして情報収集し、これを審査部門と上長で承認するプロセスを指す。
後者は、例えばクレジットカードの利用枠が上がったことがある人にはわかりやすいと思うが、最初はどこの馬の骨かわからなかったので少額取引のみであっても、実績を拵えれば当然安全も確保できたことだし足枷を外す或いは緩めるというActionを指す。 サイクルは一年くらいで充分かとは思うが、このプロセスは後述の取引管理が正常に在るべき姿で実現されていることが条件であり、そうでなくば立ち行かない。
余談だが、これらについてワンタイム取引先を利用するか否かという判断基準が関わってくる。 というのも、ワンタイムとは要は一見さんなので、一見とボリュームのある取引をあまりするものではないという前提のもとで枠を設定しないケースもあること、またそういった運用をしている企業では「一見さんは幾ら幾らまで」ということをしないので、なにをもって一見とするか、なにをもって一見から通常の得意先とするかは営業の一存でどうとでもなってしまう・・・ということもある。
これらは、ちゃんとこういうこともやっていこうよという管理側のニーズと、面倒くさい仕事の足引っ張るなグダグダしてるうちに失注したらどうすんだ的な業務側とで完全に利害関係が一致しないため、力のある営業部門の取りまとめにメッセージを発信してもらったり根回ししたりしなければ、なかなか綺麗にまとまらない。
取引管理 †
こちらは実際の取引をリアルタイムに管理するという話で、未処理受注や出荷段階の金額、現債権額などをウオッチすることを目的とする。
大方針とも密接にかかわるが、在るべき論から言えば、枠を超えた場合は入金を待つか、注文をキャンセルしてもらうか、枠を見直すかという話になるが、実務上はそうもいかない。
ブラックリストに載るほどの悪事をしでかした客ならまだしも、売ってくれと言ってきている客に「おまえ信用ないからダメ」とは、中々ならないからだ。 仕事を取ってきたことがある人にはわかるだろうが、モノ売りかどうかに関わらず、仕事を取ってくるというのは非常に大変であり、そこから長い付き合いを経てパートナー関係を築くことは、更に多大な労力を要する。 営業の人にしてみれば、頭でっかちな連中が決めたルールで、仕事なんか回らない。与信額が何千円や何万円どころか一円でも超えた程度で取引を停止しろと言うのか。馬鹿か？となるわけだ。 もちろんこれを盾に好き勝手やっていいわけないでしょ？というのが管理側の言い分なのだが、杓子定規にやっていても立ち行かないのは事実である。
なので、落とし所として「特定の人間あるいは役職に、与信ブロックを解除する権限や与信額を引き上げるを付与する」ということになるわけだが、これが常態化してしまってはまさに意味をなさない。
管理ニーズと実際とが完全にコンフリクトするため、社内や下手をすれば関係会社間でルールを統一するというハードルは決して低くないのだ。
機能的な話 †
会計での与信管理 †
ロジでの与信管理 †
まとめ前のメモ †
- トランザクションコード
- 再割当 与信確認により、伝票にブロックがかかる順序は基本的には伝票番号順であるが、これを例えば出荷日などの順にソートして再実行できる。
自動与信 †
- 項目
- 未処理受注金額フラグ これを考慮するか否か。
- 最大伝票金額 通常は与信マスタで限度額のチェックをするのだが、これを利用することで受注伝票や出荷伝票での伝票あたりの最大金額チェックが実施できる。 具体的には、100万円の与信枠があるが一度に50万を超えた取引はダメ・・・というケース。 なお、与信管理領域通貨で指定する。
- 再度与信確認 「承認した日より○日以内に○%以上の金額増加があった場合」など、伝票に変更があった場合に再度与信確認する条件を設定できる。
- 重要項目の変更に対する確認 支払条件や有効日日付などの重要項目の変更を確認する設定。 得意先マスタに設定した初期値データからの変更を監視し、受注伝票で変更があればチェックする。
- 次確認日 動的与信確認の設定では期間外の伝票は対象外とすることができるが、標準プログラムRVKRED08により与信期間に到達した時点で再度与信確認を実行できる。
- 与信グループ 標準では受注・出荷・出庫の三つ。 処理タイミングと、必要であればそれを細分化して定義する。
- 販売伝票タイプへの割り当て、与信確認項目にDの自動与信管理を設定
- 出荷伝票タイプに与信グループを割当。
- 受注明細カテゴリの与信有効化区分にチェック
- 与信管理領域、リスクカテゴリ、与信グループの組合せにより、自動与信を設定する。
- 静的と動的
- 未決済明細に対する確認 指定した支払期日を超過した日数、つまり所定の延滞日数を超えた未決済明細の金額が得意先の残高のうち指定した比率を超えた場合、与信の確認を実行する。
- 総債権額 未処理受注金額 + 未処理出荷金額 + 未処理請求金額 + 前受金や手形等の特殊仕訳債権額 + 売掛金 チェックは取引先機能の支払人 = 与信勘定に対して実施される。
- 再編成 会社コードを別の与信管理領域に割り当てたり与信管理領域通貨を変更する場合には再編成が必要で、標準レポートのRFDKLI20が用意されている。
動的与信 †
総債権額は、未決済明細、未処理請求、出荷額という静的な部分と、未処理受注額の動的な部分とに分かれる。
未処理受注額には受注残が含まれ、金額は出荷日に計算され、指定の期間(日、週、月) に応じてデータ構成に保管される。 与信確認を定義する際、将来の特定の与信期間(例: 指定期間に応じて 10 日間、2 ヶ月など) を指定し、与信の評価を目的として、指定の期間の後に出荷日が指定されている未処理受注伝票すべてを除外することも可能。 確認の静的および動的部分の集計は、与信限度を超えることができない。
関連 †
与信管理/トランザクションコード 与信管理/関連テーブル 与信管理/分野メニュー
コメントはありません。 Comments/与信管理