仕訳をいつ作るかなあと云う話
ケロロ軍曹の嘘最終回、巡回先じゃみんな予告編のフィンファンネルばかりに突っ込んでますが、何故に冒頭のウルトラセブンのセブン上司ネタに突っ込まないのか。システム業界におけるガンオタ人口の多さに、円谷勢は成す術もないのかっ。哀しい。
勝手に我が心の師匠にさせて戴いている渡辺幸三さんのブログで簿記話。しーしょおおー。東方は赤く燃えてるナア（全然関係ない感動の仕方）。
今まで関わってきた業務システムで、会計周りがくっついてるものに関しては、全てが仕訳に従属していて、売上にしろ入金にしろ仕入にしろ支払にしろ、確定時都度で仕訳を起こして、それぞれで消込行為が行われれば振替伝票を出すと云う形。
で、その消込情報は逐一仕訳に紐付いているので、消込の数は仕訳の何倍にも膨れ上がる。
よその話を聞くと、普段のお金の動きは売上・入金・仕入・支払etcそれ専用のデータで管理、仕訳は全て会計締め時点でサマって生成して、パッケージにつなげてハイおしまいって形が多い。
ただ、それだと例えば入金時に、現金1000円入ったがその内仮受金で受けて消込に使うのは800円で、残った200円を他の勘定に当てたいって要件があった場合に、ちょっと考えなきゃいけない。
- 入金登録画面では仮受金の分だけ入力、その他の勘定はパッケージの方でテケトーに入れてくれや、とユーザー様に高圧に出る。手数料とかどう分割するの？と聞かれたら自分で考えてテケトーにしてくれや、と亦高圧に出る。政治力がモノを云う。
- 入金を管理するデータ構造を、現預金1に対し貸方勘定を複数持てる様に、仕訳に近くしておく。ついでに左っかわの現預金も手数料とかぶらさげておけばほぼ仕訳にそのまま落ちて便利じゃん（手形の場合はこれは考えなくていい）。消込には右っかわの仮受金だけ抜き出して使おうよって話。
- ↑じゃあ最初から仕訳作れや。
てな事が考えられる。1はとても疲れるし、申し訳無い。2は、ここまでやったら既に「入金情報」じゃなくて、仕訳そのものだ。労力の無駄に思える。
それなら、入金情報には仮受金の金額だけを保持して、仕訳の構造は仕訳をもう作っちゃえって事で、やっぱり都度仕訳作って全てを仕訳中心でコントロールすれば、そもそも世の中そうなってんだから美しくないですかって話で、多分過去案件はそうなってたんじゃないか。
これがね、師匠の言葉ではありませんが、もう大変なんだよ。SQLが複雑怪奇、インデックスだーヒント句だーのレスポンス対策の嵐。
折角仕訳と入金情報を分離したのに、消込だなんだとその後の処理のために入金情報と同時に仕訳をトラッキングしなきゃいけない形にしたのが、勿体無かったなあと。件数が違うよ、件数が。
実は設計当初は入金情報すらなかった。仕訳がありゃ全部カタが付くじゃんってポリシーだったみたい。それが請求作るだけでもう大変で大変で、後から入金テーブルをしつらえて乗り切ったと云う経緯があったので、斯様に二重管理みたくなっちゃったのだ。
確かに仕訳中心で全てを従属させると大統一理論てな塩梅でとても愉快なんだけど、やっぱり計上→訂正→消込とかのフローに沿った部分は債務は債務、債権は債権で別管理にしておいて、仕訳は仕訳でその時々のスナップショットみたいな考えでパカパカ生成するのみにして、「どれに対する消込かって？債権側に聞けや」みたく人任せにする形が、良かったなァ、って設計した人と後から反省した。
こんなの基本中の基本なんだろうなァ。ああはじかしー。複式簿記の美しさに魅了されすぎたって話なのかな。
帳票の要件によってはそう簡単には行きそうにもないんだけど。俺も随分勉強させて戴いたので、今度亦一緒にやる時は頑張りましょうね。
つか師匠ページにリンクしちゃって、辿られたら恥ずかし過ぎる。えい、トラックバックしてしまへ。
えー、消込については亦後で考える。こいつも、消込っぱなしなら話は単純なんだけど、結構あるんだよなあキャンセルと云うか、取り消しと云うか、手戻り処理が。ああ売掛金返金、ああ手形返却。岡君、また頼むよ。
