血液ガッ手形
次は手形での入金。実は手形って未だにどう扱うのが正しいのかさっぱり判らなくて、設計した人の云われるがまま作ったので、もう本当にメモのレベル。
前受金問題は、取り敢えず全部仮受金で受けるって事にしとく。
例によって3/20締めで請求残1200円の得意先1234から2000円、3/25に手形で入ってきたとする。但し、内800円は未収入金、200円は立替金に当てる。入金テーブルはこうだな。
ID 得意先 入金日 区分 金額 --- ------ ------ ----- ------ 001 1234 03/25 手形 1000円
仕訳は現金と違って、手数料だなんだ関係ないので、これでいい。
伝票番号0325XXX 計上日 03/25 Debit Credit
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
さて、これだけあれば売掛金管理業務に関してはいいとして、手形は手形で独自に管理していかなきゃいけない。よって同時に受取手形テーブルを作る。項目はこんなもんかな。
- 受取手形ID
- 記載番号（物理的な手形に記載されている番号）
- 入金ID
- 決済日
- 金額
- ステータス（未決済、決済、不渡、とか。取立ってのが未決の後に来るのもあった）
ID 記載番号 入金ID 決済日 金額 Stat --- -------- ------ ----- ------ ---- 001 AA001 001 05/25 2000円 未決
本当はこっちにも得意先とか導出項目としてもっておきたいけど、取り敢えず保留。金額も仕訳から取ろうと思えば取れるけど、脱・仕訳大統一理論なので、持っておく。
他に、備考とか摘要とか文言を入力する要件もあったりする。あと、手形を出したのが得意先に紐つく与信先だったり、全く別だったりする事もあって、領収書を出す場合にそれも必要になるかも知れない。
で、手形テーブルは入金してからは消し込みには全然関わらない。入金テーブルが出来てるので、兎に角それを使って消し込んじゃう。ここで、与信残や債権残を考える時に、消し込みに使った手形の内未決済の分の金額を捉えなきゃいけない事があって、それへの対応については消し込みを考える時に後でまとめてやってみよう。
時は流れて05/25、日次バッチでも画面から明示的に指定でも良いと思うけど、決済業務が走る。その日が決済日になってる受取手形データを捕まえて、全部決済完了にする。
ID 記載番号 入金ID 決済日 金額 Stat --- -------- ------ ----- ------ ---- 001 AA001 001 05/25 2000円 決済
仕訳も勿論作りましょうか、こうなったら。
伝票番号0525XXX 計上日 05/25 Debit Credit
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
つまる所、手形管理は販売・売掛金管理とは殆どべっこでフローが流れて行く形になる。
で、問題は受け取った手形に対する領収書を出したり、取立ってステータス立てたいなーとか云う、手形管理業務なんだけど、得意先単位でそれが扱えればバンバンザイなんだが、これを与信先単位でやりたいって声が出て、ああどうしよう。
つまり、物理的な手形が、得意先より大きな単位で来る場合があるのだ。
例えばその得意先が東京支社、横浜支社とか有って、物理的な手形は各支社の与信先である、本社単位で扱わないといけない、とか。でも入金自体は得意先単位でコントロールせんと債権管理出来ない。
エントリーの単位と、管理する単位が違うのよ。これは困ったのだなあ。手形登録画面を別に作ってそこで手形のエントリーをして貰い、入金登録画面からは登録済み手形を参照して、得意先別に金額を割り当てていく、とか考えたんだけど、とても評判が悪かったし、画面増やすのはこっちも嫌だった。
登録済み手形に対する入金充当業務みたいな、消し込みみたいな事をまたぞろ考えないといけないし。
そんな事やるくらいなら、自分で手計算して、得意先単位に金額分割して入金登録します、と云って貰えたので、そうする事にした。与信先でまとめて来るのは、ある特定の大きい得意先に限られていて、頻度がそんなに高くなかったのが大きい。
では、手形管理側ではどう扱おうかって事になる。ここで得意先マスタの項目を確認してみる。
- 得意先ID
- 得意先名称
- あれやこれや（省略）
- 与信先ID（得意先IDへの再帰的FK）
与信先を管理してるなら、階層構造を取れるように、こんな風になってるはずだ。
よって、受取手形データから入金データを引っ張って、入金データの得意先から与信先をひっぱって、与信先単位で金額を合計して、手形管理業務では扱う事にする。これは都度SQLでGROUP BYしても良いし、ビュー作っても良い。
SELECT
得.与信先ID,
手.記載番号,
手.入金ID,
手.決済日,
手.ステータス,
SUM(手.金額)
FROM 受取手形テーブル 手
INNER JOIN 入金テーブル 入
ON 手.入金ID = 入.入金ID
INNER JOIN 得意先マスタ 得
ON 入.得意先ID = 得.得意先ID
GROUP BY
得.与信先ID,
手.記載番号,
手.入金ID,
手.決済日,
手.ステータス
やっぱ得意先ID、持っておこうかな・・・。
てな訳で、お客様には「記載番号とか決済日とか、きっちり間違えずに同じものを入力しないと、別の手形と判断しちゃいますんで、そこんとこ夜路死苦」と念を押さないといけない。
うーん、これでよかったのだろうか。摘要とか備考とかあった場合は結構大変そうだ。
因みに、受取手形登録業務を入金登録と分けて、入金を充当していく場合は、受取手形テーブルに与信先IDを追加する。で、こう云うテーブルが必要になる。
あっ、でも入金:手形が1:Nには成り得なくて、必ずN:1になるはずで、充当金額は入金テーブルからひっぱれば良いから要らないか。受取手形IDと入金IDを複合キーにしたっていい。複合キーが嫌いじゃない人は。
世の中複合キーに対する風当たりが強いのを知って、色々と考えている六であった。
あっ、複合キーは良いとして、充当金額は必要！未収入金とか立替金問題を忘れてた。必ずしも消し込みに使える入金額（つまり仮受金）の合計額が手形の金額って訳じゃないんだ。あーややこしい。
血液ガッ手形・補遺
ちょっと（いやかなりの）問題発覚。失敗失敗。
SELECT
得.与信先ID,
手.記載番号,
手.入金ID,
手.決済日,
手.ステータス,
SUM(手.金額)
FROM 受取手形テーブル 手
INNER JOIN 入金テーブル 入
ON 手.入金ID = 入.入金ID
INNER JOIN 得意先マスタ 得
ON 入.得意先ID = 得.得意先ID
GROUP BY
得.与信先ID,
手.記載番号,
手.入金ID,
手.決済日,
手.ステータス
このSQLでは大前提として、手形は必ず与信先単位で管理する、って事になってしまう。明示的に得意先単位で管理したいって事もあるはずだ。
与信先がその得意先と等しい場合は問題ない。でも、与信限度額管理は本社でやってるけど、手形は支社から来ましたー、支社に領収書出して下さーいって要件で、どかーん、だ。
実際、俺、こんな風に作ってなかったし。さて、どうしたかと云うと、受取手形テーブルの項目を再考。
- 受取手形ID
- 記載番号
- 入金ID
- 発行元得意先ID ←追加しました
- 決済日
- 金額
- ステータス
これでどうだ。入金登録時、画面上の発行元得意先入力欄に、今入金登録しようとしてる得意先をデフォルト表示してあげる、って寸法。で、債権管理上の得意先と違う場合は適宜変更してね、と。勿論入力必須。
入力確定時、発行元得意先と入金の得意先との整合性チェックの要否、仕様などはお客様と要相談。
手形管理業務で扱う単位のSQLはこうなる。
SELECT
発行元得意先ID,
記載番号,
入金ID,
決済日,
ステータス,
SUM(金額)
FROM 受取手形テーブル
GROUP BY
発行元得意先ID,
記載番号,
入金ID,
決済日,
ステータス
とってもシンプル。
あっ、入金IDでGROUP BYしちゃ駄目ジャン、折角合算してんのに！今気が付いた。バカだなあ俺。
SELECT
発行元得意先ID,
記載番号,
決済日,
ステータス,
SUM(金額)
FROM 受取手形テーブル
GROUP BY
発行元得意先ID,
記載番号,
決済日,
ステータス
これで、ケーオツですか。さあ領収書発行でも取立でも不渡でもやりやがれ。
