現預金の入金でウーンウーン
取り敢えず請求は一段落したので、次は消し込んだれと思ったが、消し込む相手の入金を考えてみる。
入金にも大概色々ありまして。
- 現預金で入金
- 手形で入金
- 債務と相殺
こんな所ですか。
この内債務と相殺は、以前の案件では稼動後に出た追加要望だったんで、入金側で買掛金で入金して、それとは別に支払側で仮払金で消し込んで、その間を振替伝票を自由に仕訳入力出来る画面で入力して間を取り持つって事をやってもらってて、自動で債務側を消し込んだりするナイスな仕組みはやった事ありません。今度これも考えてみたいなあ。
話は逸れたが、まずは入金を管理するテーブルが要りますな、と。項目はまずはこんな感じでどうか。
- 入金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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
うー、ここまで記憶だけで資料なしで書いた。どうしよう、自信が揺らいできた。まあいい。
以上のデータを一回の処理でバカバカバカーンと、あと入金テーブルのデータも、作る訳。訂正は勿論赤黒切りますよ、気が遠くなりますな。画面構成も悩み所、入金伝票片手にパカパカとなるべくテンキーだけで連続入力出来ねば嫌がられる。
これで何とか、現預金での入金は形になったんとちゃいますか。複雑な仕訳は仕訳テーブルに任せて、その分作ったら作りっぱなしのスナップショット扱い、あとで帳票でも何でも出して頂戴って塩梅。
で、入金テーブルでは複雑な仕訳は関知せず、なるたけ無駄の無い構えにして、処理の方が複雑になりがちな売掛金管理に命を賭けて戴く。これを仕訳大統一理論でやったら、そりゃもうプログラム側は大変だってのは察しがつくでありましょうなァ。
次は手形入金と手形をどうやって管理すべえの巻、か。
今度は前受金でウーンウーン
渡辺幸三さんブログのコメント欄で、前渡金を購買システムで扱うか云々質問なさっている方がいらっしゃって、俺の関わったシステムでは買掛金管理で余計に払い込んでおく要件は全く無かったのでこれは全く経験が無い。こいつも考えてみたいですな。
ただ、その後の前受金と売掛金管理に関しては、上に書いた過入金の場合に請求残がマイナスになって次月繰越ってのがそれに当たると思うんだけど、「入金は全部仮受金で受けちゃいますから」の一言で確認をとって、過入金分を前受金で受ける事はしなかった。
販売システム側の視点では、未消し込み残のある入金テーブルのデータがある、と云う状態。会計につなげる用データの視点では、仮受金残のある仕訳テーブルのデータがある、と云う状態。
で、次月以降、また新たな請求が起きたら、その仮受金を使って消し込んで行く形。勿論、仮受金残が残ったまましばらく取引が無かったり、取引停止になった場合用に、仮受金返金処理ってのも作った。ただ仮受金に対して赤黒切るだけじゃなくて、支払処理の立て付けと連動させなきゃいけない。それはまた別の話。
で、過入金分・前受金対応ってやろうとすると、これまたウンザリする世界が待ってそうだなあ。
いや待てよ、それは以前やったシステムの仕訳大統一理論に則ってるからめんどそうなのであって、消し込み行為は仕訳・勘定に関係なく入金テーブルで制御する方針に今回は変更したんだから、前受金対応は、入金登録時に、その時点での請求残との兼ね合いでやっちゃえないか？
3/20締め請求残が1200円として、3/25にはもう現金で入金されちゃいました、しかも気前良く3000円も。但し、その内800円は未収入金に対して、200円は立替金に対しての入金とする。こうなるか。
ID 得意先 入金日 区分 金額 --- ------ ------ ----- ------ 001 1234 03/25 現金 2000円
で、仕訳はこうなる。はず。
伝票番号XXXXX 計上日 03/25 Debit Credit
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
で、渡辺さんのおっしゃる売掛金に対する「前受金充当業務」ってのは、実際の勘定が仮受金だろうと前受金だろうとこっちは入金テーブルで統一的に扱うので、これから考えようとしてる「入金消込業務」で一括で扱えやしないだろうか、と。
いやそんな単純じゃない、消し込み時に生成すべき振替伝票の借方に、仮受金が来るか、前受金が来るか、きっちり判断つけなきゃいけない。でも業務上、それを意識せずに一括でやりたいには違いない。裏ではやっぱり密接に仕訳と関わっていかなきゃいけない。
もしかしたら今までの方針、つまり
- 売上・請求をパカパカ作る。
- 入金は入金でこれまたパカパカ作る。
- 入金消込業務で初めて両者がこんにちはする。
と云うのが限界なのかなあ。入金時にもう消せる奴は消して下さいよ、と。
ただ、前にも書いたけど、請求書上に入金が反映されて、残が正常である事を確認するまで消し込み業務を待ちたいって声もあるにはある。
いや、入金テーブルに項目を増やしてみよう。前受区分とか。
ID 得意先 入金日 区分 金額 前区 --- ------ ------ ----- ------ ---- 001 1234 03/25 現金 1200円 非前 002 1234 03/25 現金 800円 前
で、これを使って消し込めば、振替伝票の借方が判る。ウーンウーン。
あーもう。ダメだ、仕事しよう。
でも会計上、仮受金の残が残ってますわーって帳簿で問題なければそっちのが良いけどなー。問題あったら今動いてるシステム、監査が入って怒られかねない。取り合えずこないだは怒られなかったらしいので、ケーオツと踏んだ。うむ。
うーむ、ここまでフォローせんといかん案件て、そうそうないと思いたいんだけど（希望的観測）、まーまー、考えたいお年頃なの、机上の空論でもいいの、パズル・販売管理システムなの。
岡君、タスケテ〜。
前受金つづき
大体がろくに会計の勉強もせずに現場で経験した事であーだこーだと考えるからイケナイ。ずっと資料なしで海馬に残存する記憶だけで考えてるし。ここで勘定について調べてみよう。
ああそういや前にちらりと見た販売管理システムで、入金受ける時に仮受金と売掛金と選べるの、あったあった。こう云う事だったのか。そいつは入金と入金消し込みがほぼ同時だったと思う。
要するに違いは、入金の目的が不確定か商品代金と決まってるか、と云う事だけみたいだ。それ云ったら今回の
- 売上請求をパカパカ作る
- 入金は入金でこれまたパカパカ作る
- 入金消込業務で両者が初めてコンニチハする
と云うフローだと、根本的に入金のタイミングは請求・売上に関係なくお客様の裁量で自由な訳だから、かつ目的は商品代金に決まってる訳で、全部前受金だっていい気がする。いいのか？よくなさげだなァ。
うーむしかし、微妙だ。過入金分をどう扱うか、レフリードッチデモイイジョーって感じに取れる。ここは口八丁手八丁で「全部仮受金！」って事にしたい、是非したい。
どうせ消し込んだ途端に
○売上ましたー 売掛金 700円 / 売上高 700円 売掛金 500円 / 売上高 500円 ○入金しましたー 現金 1200円 / 仮受金 1200円 ○消し込みましたー 仮受金 1200円 / 売掛金 700円 / 売掛金 500円
て、とっとと振り替えられておしまいだし。ずーっと仮受金が残ってて問題だったら仮受金返金業務の発動だろうし。上記仕訳の出来方はえーと、どう実装するかで色々ですが取り合えず。
まあ結局はお客様ルールに合わせてって事になるんだけど、お客様側でも「うーんどっちでもいいなー」って感じだったらもう仮受金で押し切る、そうしよう。
ウーン、何か穴がある気がする。何か浅はかな事やってる気もする。だがしかし、ちっとも先に進まないので、取り合えず次行ってみよー次どうぞー。
請求書上で消し込みをシミュレートする訳・補遺
実際にデータとして売掛金が消し込まれてなくても、請求書を出力した時点でその請求期間内の入金を乗せて、擬似的に消し込みを行って結果を表示しなきゃいけない、と前に書いたけど理由が不十分だった。
消し込み忘れて請求書出力、とか、一旦残を確認してから消し込みしたい、とかそんな理由だけじゃなくて、決定的な理由は、前受した入金に関してだ。そうそう、忘れてた忘れてた。いちようメモっておく。
- 3月に請求データを作りました。
- 請求書を受け取った得意先が請求書通りに入金してくれました。
- 3月分の請求済売掛金に対してその入金を使って消し込みました。
- 4月にも売上がありました。
- 4月の請求書を出したらさっきの入金が乗って、前月残が綺麗に消えました。
- 4月分の売掛金が綺麗に残りました。
これなら問題ない。次の例の場合はどうなるか。
- 3月に請求データを作りました。残は1000円です。
- 請求書を受け取った得意先が1200円入金してくれました。
- 3月分の請求済売掛金に対してその入金を使って消し込みました。
- 4月にも売上がありました。売掛金は1000円です。
- 4月の請求書を出したらさっきの入金が乗って、前月残1000円が綺麗に消えました。
- 4月分の売掛金1000円も勿論記載されています。
- 4月分の売掛金の内、まだ消し込まれてない入金200円分が消えて、当月残は800円です。
と、こうならなきゃいけない。
だがしかし、擬似的に消し込みでなく、実際にデータとして登録された消し込みデータだけを表示すると、最後の200円はどうやっても消えない。何故か。請求書を作らないと、消し込み出来ないからなのだー。
4月の請求データを作ろうって時に、それに対して消し込みは出来ない。でも得意先は4月分も見越して前受金を払ってるから、4月請求残は800円である事を期待している。
じゃあ請求データ作らなくても、売上計上されてりゃ消し込める様にすればいいじゃん。勿論対象は、以前考えた請求対象フラグが立ってるもののみ、で。ほんで、消し込んでから請求データを作ればいい。
てな風に簡単には行かない。基本的に得意先はどれだけ商品を買ったかを請求書で判断し、それに対して入金してくれる。殆どのケースは請求書通りの金額が入金される。
消し込みを行うとき、得意先によってはけっこうな件数の売上を、請求と云う単位でまとめて取り回せないととてもじゃないがやってられない。請求単位での一括消し込みなんて技も出来ない。数百件の売上明細行のチェックボックスをえっちらおっちらつけて、色んな組み合わせを考えて、よし、これで入金額と一致した、ふーやっと終わった、消し込みボタンぽちっとな、なんて可哀想だし、要件とかけ離れ過ぎる。
- 追記
- 大体が、請求対象フラグは赤黒切ったりで時々刻々と複雑に（そうでもないか）変化する事は前に見たので、またぞろ消し込み済みの元伝はどうとかロック機構を考えなきゃいけない。却下却下！
- さらに追記
- それ以前に、売上単位の消費税と、請求書上で売上を合算した時の消費税の誤差の問題がある。得意先が入金してくる金額は勿論後者に対してである。却下却下！大却下！
そんな訳で、消し込みは請求データ作らないと（もっと厳しく実際に印刷しないと、って場合もある）やっちゃダメ、絶対、ってのがよい。
大体画面構成からして、恐らく消し込み対象って事で請求の一覧を表示する事になるので、請求しなきゃ画面にすら出て来ないはずだ。
そんな訳で、請求書に表示する消し込み情報は、メモリ上でえっちらおっちらやりましょうって話になるのだった。で、これを仕訳大統一理論でやろうとして、本番稼動直前に破綻していやー大変だった事よ。急遽入金テーブルをしつらえた訳だ。
これね、結構厚い厚い処理なのでここでパパパとは書けない。トライ・アンド・エラーでぐっちょんぐっちょんになったソース、涙無くしては見れない。これを次の案件では綺麗にしたいなあと思う。
