消込と云うドグマ
うーむ、そんなフレーズが頭をよぎるのであった。
請求、入金があって、それをつなぐ形で消込がある形は、販売システムで閉じた場合は運用を単純化する意味でも有効だと思います。直感的だし。
ただし、仕訳まで視野に入れると割りとややこしい。いやかなりややこしい。
請求と云うか売上に関しては当然こうです。
借方 | 貸方 ---------------------------- 売掛金 100円 | 売上 100円
で、入金に関しては、前にも書いたけど、全部仮受金で受けちゃおうぜ方式を取ったんだった。
借方 | 貸方 ------------------------------ 当座預金 200円 | 仮受金 200円
で、消し込むんだ後、振替仕訳を作る。
借方 | 貸方 ------------------------------ 仮受金 100円 | 売掛金 100円
で、残としては100円あまってるから、それは過入金って形。きっちりやるなら前受金って勘定にせんとならんけど、ここは仮受金のまま繰り越して次回使おうってのが今までのおさらい。
考えてみるとこの考え方は仕訳大統一理論を採用していたからやらんといけなかっただけなんじゃないかと。仮受金で受ける必要はないんじゃないか、と。どうしても入金と消込のタイミングがずれるから、一度仮受金で受けときましょうかねー、って云う。
しかもこの消込処理ってのがもう、バグ製造マシーンでねぇ。消費税の差損益に対する消込はどうすんだとか。ストアド書いたの俺じゃないけどなー。でも俺がやっても大変だったと思う。
いっそ消込っての、やめちゃおうか。
渡辺さんのモデルだと、入金（売上受領明細登録）の画面イメージを見ると、請求でなく、売掛金・前受金のサマリを参照しつつ受領金額を入力する形。そうなると、月次バッチでこの受領データから直接振替仕訳が作れるはず。
借方 | 貸方
------------------------------
当座預金 200円 | 売掛金 100円
| 前受金 100円画面を工夫すれば、お客様のオペレーションの負担も左程ではないと思う。最初に通帳に記載された金額入れてもらって、前月売掛残を見て前受金分を計算してデフォルト表示してあげるとか。
あと問題は、請求単位でオーバーデューを管理するかどうかって所だけど、これはもうお客様によりけりでしょうな。ナイスな販売システムとしては、渡辺式のがよさげ。
一回頭クリアして、この路線で再考かなあ。いやーマイッタ。次々と既存案件の問題児に対するソリューションが。
やっとこ仕訳のとこまで見る
うーむ、よい！ちょっと奥さん、これはいいかも。
消込とかやって、ここの明細単位の売掛金と回収ががっつり手を組んじゃってるから、後々の手形返却だの、過入金の返金だの、返品分だけマイナスだけで残って取引終了しちゃった所への売掛金の返金だので、すんごいややこしい処理をしないといけなくなる。
消込キャンセルしてー、請求のステータス変えてー、売上明細のステータスも変えてー、マイナス金額でダミーで入金を作ってー、場合によって支払指示データも作ってー。
しかもここらへんの返金処理、当初のスコープになくて、本番稼動後1ヶ月か2ヶ月で「聞いてないよ」要求として浮上、1週間足らずで急いで作ったんだよなー。死ぬかと思った。
それが！仕訳大統一理論をやめて「消込？それ美味しいの？」状態となれば、なんてシンプル！しかも間違えて登録してもお客様運用でやり直しOK！何度データパッチ当てに現地に行ったことか・・・。
既存案件は、得意先が請求単位どころか売上明細単位で検収あげて都度入金する事がままあって、よって明細単位で回収の状態を把握しなきゃいけなかったのでどうしても消込処理は必要だったんだけど、確かに一般的ではないでしょうそれは。
見えるぞ、私にも敵が見える！
回収の振込手数料にかかる消費税が管理されてないように見えるんだけど、そう云うもんなのかな。
あと、仕訳見出しの粒度がわかんないなー。各仕訳パターンごとに見出し作っちゃった方が判りやすいかな。
画面レイアウトも勉強になりました。手形の登録と回収の登録が別タイミングなのですね。俺もそっちのが良いと思うんだよなー、でもお客様がいやだっていうから・・・・。
プラマイがややこしいんだこれが
「売上受領データ管理」の中の、「売上受領明細の保守／前受金返還」の返還なんだけども。前受金〜とはなってますが、同じ画面で同時に売掛金の返金も出来るスグレモノ。
売上受領指示テーブルの「取引区分」の仕様はこうなってます。
１＝現預金受領、２＝受取手形受領、３＝自社手形受領、４＝前受金充当、５＝前受金返還（現預金）、６＝貸倒損失計上
前受金を得意先に返す場合は、「５」がセットされる訳です。
で、「売上受領明細の保守／前受金返還」の説明ではこうなってます。
パネル上の「売掛金返還額」は受領明細の「取引額」のマイナス値としてセットされ、「前受金返還額」は「前受金」のマイナス値としてセットされる。
つまり、売上受領指示テーブルに、金額としてそれぞれ「入力値 × -1」の値がセットされるって事ですね。
サマリーを作る時などに便利なのでこうするのはよくあります。
で、そのサマリーはどうなってるかと云うと、「月次売上受領取引SUM」ってのがそうですね。項目多いので端折りますがこんな感じ。
- 事業所Ｃ
- 年度
- 月序
- 月初売掛金残高
- 月初前受金残高
- 月間課税売上高
- 月間免税売上高
- 月間非課税売上高
- (中略)
- 月間売掛回収額（現預金）
- 月間売掛回収額（受取手形）
- 月間マイナス売掛返還額（現預金）
- (中略)
- 月間前受金返還額（現預金）
- (中略)
- 月末売掛金残高
- 月末前受金残高
つまり、取引区分ごとにサマリーが分かれてる訳です。こりゃ便利。ここからそれぞれのカラムの仕訳パターンで仕訳を月次バッチで作る訳です。
では、仕訳はどうなってるかと云うと、「仕訳生成処理（売上収益）」って所に書いてあります。
■仕訳科目の設定 № ＜借方＞ ＜貸方＞ ====================================== 01【月間売上増（月間課税売上高＋月間免税売上高 ＋月間非課税売上高）】 売掛金 売上 ------------------------------------------------------------------- 02【月間売上減（月間回収時値引額＋月間売上返品額 ＋月間支払リベート額）】 売上 売掛金 ------------------------------------------------------------------- (中略) ------------------------------------------------------------------- 12【月間マイナス売掛返還額（現預金）】 売掛金 現預金取引※ ------------------------------------------------------------------- (中略) ------------------------------------------------------------------- 16【月間前受金返還額（現預金）】 前受金 現預金取引※ ------------------------------------------------------------------- (中略) ====================================== ※対照勘定（全仕訳中で貸借が一致して残高がゼロになる）
て事はですよ、サマリーにはマイナス金額じゃなくて、画面上の「売掛金返還額」「前受金返還額」に入力した通りの金額が入ってた方が良い筈。
よって、売上受領指示テーブルの「取引額」もわざわざマイナスにせんでもいいんじゃないか、と。サマリーもカラムが分かれてるんだし。
そうでないと、どこかでまたもう一回プラマイを逆にしなきゃいけない。
うーんと思って、今度は「仕入支払データ管理」の「前渡残高決済指示の保守」を見てみました。回収と支払が対照になっているように、前受金と前渡金は対照となってますんで、似たような処理になってる筈です。
すると、こっちでは特にプラマイひっくり返すような事はしとらんのです。あとは仕訳作る所まで殆ど同じ。
符号が付いてる付いてないで処理を制御するのは極力避けたいのが人情ですし、そもそも取引区分があるし、サマリーも別枠で集計してる訳ですんで、これはあれかな、作ってる内に方針を変えたものの修正漏れって感じなのかな。
念のため、今度は売上だの仕入だの関係なく、入出金実績テーブルがどうなってるかを見てみましょう。「現預金データ管理」の「入出金実績生成（売上受領指示）」にはこうあります。
◆入出金実績処理の対象となる取引区分／金額項目と、それぞれに対応するＣ／Ｆ区分は以下のとおり：
＜取引区分＞ ＜金額項目＞ ＜Ｃ／Ｆ区分＞
１＝現預金受領 受領額 営業収入
５＝前受金返還 受領額（出金として） 営業収入
この「出金として」ってのは入出金実績テーブルの入出金区分に「出金」をセットするって事だと思います。で、前述のポリシーに基づき、取引額には画面で入力した金額を入れるとします。
でもこの「Ｃ／Ｆ区分」ってのがちょっと心配です。そんな訳で、キャッシュフロー計算書の出力を見てみましょう。「決算データ管理」の「Ｃ／Ｆ計算書発行処理」です。
指定期間内に計上された入出金実績をその「Ｃ／Ｆ区分」毎に集計して一覧印刷する。
特に入出金区分でプラマイ変換する、とは書いてないんですね。当たり前だから書いてないだけなのかも知れませんけど、微妙です。
本人に聞けばいいんだよ。んだ。そうしよう。
それにしても、本当、頭がすっきりしたぞこれは。返金処理などの割りとイレギュラーな運用での複雑怪奇な建て増し処理や、「お金扱ってんだからもうちょっと慎重にやってくれよ」とお門違いな文句を云いたくなる入力間違いに滅法弱い後戻りが効かない処理などが極力廃されてるように思います。
ちゃんと設計するってこう云う事なのよねぇ。あーあ。
