現預金の入金でウーンウーン
取り敢えず請求は一段落したので、次は消し込んだれと思ったが、消し込む相手の入金を考えてみる。
入金にも大概色々ありまして。
- 現預金で入金
- 手形で入金
- 債務と相殺
こんな所ですか。
この内債務と相殺は、以前の案件では稼動後に出た追加要望だったんで、入金側で買掛金で入金して、それとは別に支払側で仮払金で消し込んで、その間を振替伝票を自由に仕訳入力出来る画面で入力して間を取り持つって事をやってもらってて、自動で債務側を消し込んだりするナイスな仕組みはやった事ありません。今度これも考えてみたいなあ。
話は逸れたが、まずは入金を管理するテーブルが要りますな、と。項目はまずはこんな感じでどうか。
- 入金ID
- 得意先ID
- 入金日
- 入金区分（現預金・手形・債務のどれか）
- 金額（実際に消し込みに使える金額）
まあ取り敢えず。
もう取引先なんて曖昧な表現はやめて、得意先にした。後で支払や相殺を考える時難儀しそうなので。本当は同じ得意先でも売上先とか出荷先とか請求先とか要件によっては色々あるんだけど、取り敢えず得意先。
さて、3/20締め1200円の請求書を出した得意先（IDは1234）から、4/1に1000円だけ入金がありました、と。
ID 得意先 入金日 区分 金額 --- ------ ------ ----- ------ 001 1234 04/01 現金 1000円
これを使って請求にぶらさがる売上明細を消し込む訳ですが、どうやらお客様はすぐさま消し込む事はしないで、次の請求書を出して、その請求書に当月入金が記載されるまで待ったりする様です。請求書上に記載される残が思った通りなのを確認してからデータとして確定したいんじゃないですかね。消し込みってある意味確定行為ですから慎重にもなりますわな。
この、実際はデータとして消し込まれてないのに請求書上では請求残から入金を差し引かれてるように記載しなきゃいけないのがこれまた面倒臭い（勿論実際に消し込まれてても同じ）。データとしてまだない要素、つまりはこれから行う予定の処理の結果を、帳票出力と云う処理の中でシミュレートしなきゃいけないんだなあこれが。
何故かと云うと、消し込みってのはシステム側、つまり（我々にとっての）お客様の都合で行う事だからで、お客様のお客様、つまり得意先からしてみりゃデータとして消し込まれてようがなんだろうが、請求期間内に払った金はちゃんと請求書に反映されてなきゃ困る訳なのだな。
だから、うっかり消し込み忘れて請求書出力しちゃいました、あっ入金が乗ってなくて請求残が膨れてます、得意先からクレームが来ちゃいましたよ！てな事はあってはならない訳。請求書のヘッダに過去の残がある請求の一覧を出して、その残金額から入金額で消して行く。入金が無くなった所でループは終わって残ありの行がまだあればそのまま出す。入金があまったら、当月請求残はマイナス金額となる。これをデータに頼らずメモリ上でやる訳よ。ただの請求書って名前のビューだから。
あーすぐ話が逸れる。ここで、お客様から要望が。
今の所この入金の仕組みでは仕訳はフォローしてないが、話を見えやすくする為にあえて勘定で話すと、売上を消し込む為に使う入金は仮受金で受ける事が多い、て云うかそのパターンしか知らない。
現預金 1000円 / 仮受金 1000円 手形だったら 受取手形 1000円 / 仮受金 1000円
ところが、お客様の話だと、得意先からの入金は何も売上に対する支払だけでない、と。こんなパターンもありますよ、と。
〇土地とか株とかを売却したりのお金が入りました、の巻 現預金 1000円 / 未収入金 1000円 〇得意先の費用なぞを立て替えてやったのを返して貰いました、の巻 現預金 1000円 / 立替金 1000円
そんなの、こちとら「販売管理システム」なんすから、別枠でパッケージとかで登録して下さいよ、と云いたいのをぐっとこらえなきゃいけない事も、あるのだなァ。
でもお金の動きとして、ある銀行口座に何月何日に幾ら入りました、と云う事実はひとつしかない。それを「入金登録画面」で事実のまま登録出来ないとはなんたる事か、と突っ込まれるのもシャクなので、ちょっと頑張ってみる。
で、この話題は仕訳をいつ作るかなあと云う話でも出したけど、これを入金テーブルでフォローするともう仕訳となんら変わらなくなるんで、いっそ仕訳も作ってしまえ、と考える事にする。
- 入金テーブル
- 実際に消し込みに用いる入金額を保持する。その金額は仮受金で受けた分と等しい。
- 仕訳テーブル
- 純粋に仕訳のデータ。この後の消し込みとかには関与しない、作ったら作りっぱなしデータとして位置付ける。
さて、仕訳パターンを見てみましょかね。実際に銀行に入ったお金は2000円。その内、未収入金を消す為の分が800円、立替金を消す為の分が200円として、その残りが仮受金として使う事が出来る。
考え方は、仮受金で受ける分は「余り」って感じ、画面を具体的に考えると、仮受金の金額は表示のみ項目で、借方金額からみ収入金・立替金を引いた金額が自動で表示される。これが良い。
で、出来る仕訳はこう。データしてどう持つかは、仕訳テーブルの設計によりけりで、面倒なので後回し。
Debit Credit
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
入金データはさっきと同じ。
さて、ただの入金データじゃなくて仕訳に足を突っ込んだからには、話はこれで終わらない。支払条件とか現金現金と云うけど、本当に現金で払われる事は無くって、現金とは即ち手形じゃないと云う意味くらいでしかなく、つまる所預貯金な訳だ。で、得意先はお客様の口座に振込みする事になるが、その時に当然ながら手数料が発生する。
この振り込み手数料を誰が持つかと云うと、日本の商習慣で何故か（我々にとっての）お客様なのだねぇ。だから、仮受金として債権を消せる金額と、実際に預金に入ってくる金額が違うんだな。ああ面倒。
Debit Credit
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
受取手数料ってのは、手数料収入を表す収益勘定なので、借方にくれば損失になる。仮受金その他として2000円受け取れるはずが210円減ってるので、合ってる合ってる。
これだとまだ正確な仕訳と違う。210円ってのは、手数料200円+消費税な訳で。収益で発生する消費税は仮受消費税って事でこれが正しい（と思う）。
Debit Credit
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
うー、ここまで記憶だけで資料なしで書いた。どうしよう、自信が揺らいできた。まあいい。
以上のデータを一回の処理でバカバカバカーンと、あと入金テーブルのデータも、作る訳。訂正は勿論赤黒切りますよ、気が遠くなりますな。画面構成も悩み所、入金伝票片手にパカパカとなるべくテンキーだけで連続入力出来ねば嫌がられる。
これで何とか、現預金での入金は形になったんとちゃいますか。複雑な仕訳は仕訳テーブルに任せて、その分作ったら作りっぱなしのスナップショット扱い、あとで帳票でも何でも出して頂戴って塩梅。
で、入金テーブルでは複雑な仕訳は関知せず、なるたけ無駄の無い構えにして、処理の方が複雑になりがちな売掛金管理に命を賭けて戴く。これを仕訳大統一理論でやったら、そりゃもうプログラム側は大変だってのは察しがつくでありましょうなァ。
次は手形入金と手形をどうやって管理すべえの巻、か。
