計上日はでけえジョ〜
さて、請求キャンセルと売上訂正も問題なさそうだし、次は支払でもいじろうかな。
バカもの。お前の検証は、出荷基準しかフォローしておらんではないか。
あっ、サタン様の声が！
お前の検証では計上日は処理日にカレンダーテーブルだかで紐付いた当月側計上日をシステム側で自動セットするような、そんな場合しか考慮しておらん。お前のシステムでは、富山の薬売り方式商品もあったはずだろう。あれは云わば検収基準ではないか。
そうだ、そうでしたサタン様。富山の薬売り方式。
- 複数商品をパッケージにして出荷。この段階では売上計上はしない
- あるタイミングでパッケージが返却される。
- 返却されたパッケージを確認、数量が減った商品の分のみを売上とする。
- 売上計上日は返却された日とする。
つまり、使用数量の確認→売上の登録の間にタイムラグが1日以上発生する場合があり、計上日はシステム利用者からの任意の日付の入力を受け付ける必要がある訳だ。
前回と同様の取引先でやってみよう。
- この取引先の通常の締め日は20日締め。
- 現在の最新締め日は2/20。
- 前月請求で綺麗に消し込まれて請求残は0円。
あと、計上日の入力仕様は以下とする。
- 処理日からカレンダーテーブルを参照して、オーバーラップ期間を確認。
- オーバーラップ期間外だったら、計上日は処理日と同じ年月のみ許可。
- オーバーラップ期間だったら、計上日は処理日と同じ年月もしくは、前月のみ許可。
- ただし、
計上訂正の場合、当月側計上に対して決算側で赤黒を切るのは禁止！だってややこしくなるもん！これは飲んで貰えるでしょ！[追記]いやこれは赤の計上日をどうセットするかの仕様さえしっかり作り込めば行けそう。それについてはまた後で。現状は計上日は赤黒同日とする。 - 売上計上・入金計上に関しては、その取引先の最新締め日以前の日付は禁止。
3/15に返却された分の売上をまずは新規計上する。
001 3/15 黒 1000円 請求対象
で、前回よりもうちょっとややこしくしよう。3/18くらいに、締め前に001に対して計上訂正をしてみる。
- 001の計上日は3/15。
- 最新請求締め日は2/20。
- よって001は未請求ですね、と。
なわけで、まずは001の赤黒区分を元に更新、請求対象区分も仕様通りに更新。新規追加する赤黒明細も仕様通りに追加してみる。
ただし、今回は計上日は自由入力なので、この場合利用者は元と同じ計上日を入力したものとする。
001 3/15 元 1000円 非対象 002 3/15 赤 -1000円 非対象 003 3/15 黒 1200円 請求対象
時は流れて3/21になりました、と。20日締めを行う。請求は以下になる。
明細1 1200円 003
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
同日、最新請求締め日が更新された絶妙のタイミングで営業のミスが発覚、計上訂正が行われる。この時最新請求締め日は3/20なので、最新黒票003と同じ計上日は入力出来ない。営業は涙を飲んで次月請求に持ち越す事を承諾する。
で、最新請求締め日は3/20なので、003は請求済みですね、と。よって売上明細はこうだ。
001 3/15 元 1000円 非対象 002 3/15 赤 -1000円 非対象 003 3/15 元 1200円 請求対象 ←請求済み 004 3/21 赤 -1200円 請求対象 ←未請求 005 3/21 黒 1500円 請求対象 ←未請求
さてさて、ここで経理の人が思い直して、やっぱりちゃんと綺麗な形で請求に乗っけようって話を営業とつけたとしよう。やるべき事は以下だ。
- 3/20締め請求をキャンセルする。
- 3/21の売上を3/15に訂正する。
- 亦締める（まあ、やらしい）。
うわーやめてくれー。でもやるんだよ。
- 005が今回の最新黒。
- 請求キャンセルしたので最新締め日は2/20
- よって005は未請求と判定
001 3/15 元 1000円 非対象 002 3/15 赤 -1000円 非対象 003 3/15 元 1200円 請求対象 ←未請求（キャンセルされた） 004 3/21 赤 -1200円 請求対象 ←未請求 005 3/21 元 1500円 非対象 ←未請求 006 3/15 赤 -1500円 非対象 ←未請求 007 3/15 黒 1500円 請求対象 ←未請求
締めてみますか。締める売上の条件は以下だったな。
- 計上日が2/21〜3/20
- 請求対象フラグがたってるもの
明細1 1200円 003 明細2 1500円 007
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
どかーん。
膨れてしまった。1200円が余計だ。この1200円はどうなるのかと云うと、4/20締め請求に赤が乗るのだ。
こんな感じ。
明細1 -1200円 004
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
これでは取引先から怒られてしまう。
何が問題かと云うと、請求済み、未請求の判定を、最新請求締め日と計上日から都度判断して動的に導出しようとしてるからである。
つまり、データが持つべき属性である「請求済みか否か」を属性としてではなく、ロジックとして内包しちゃってるからだ。
だから何時も云っておろう！データは静的でなくてはならぬ、と！データにロジックを持ち込む事は決してやってはならぬ、最大の事項である！データを静的に保つためには、アプリケーション側で如何なる努力も惜しんではならんのだ！アホボケカス死ね原始人！
ああサタン様！申し訳御座居ません！
教訓、データにロジックを持ち込むのはやめましょう。
いやおふざけでなく、ステータス管理の重要性と共に、師匠格の人にまず叩き込まれた哲学なんだこれが。うーん、こう云う所で身に沁みるとは。
この場合、導出属性だからと云って都度都度導出しないで、「請求済み区分」みたいなのを立てろって事だ。単に売上明細に請求番号などを持つだけでも良い。NULLが嫌なら未請求のものには「000000」とか突っ込んでおけば良い。
俺が、ファウラー先生のこれ→http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=DomainLogicAndSQL&key=sqlを読んで、なるほどさすがファウラー先生と思いつつどうも居心地が悪かったのは、このデータにロジックを内包させる事の恐ろしさがスコンと抜けてるからだ。ディスカウントするならディスカウント区分立てるでしょ、注文ってのは過去実績なんだから。
まあドメインモデルとかトランザクションスクリプトとかの解説用の、極々単純な判り易いサンプルだから其処までガーガー云うのも無粋ってもんですけど。
あっ、よく考えたら動的に導出しようと区分持とうと、再現するじゃないですかこれ！サタン様、ファウラー先生に謝って下さいよ！
・・・・・・（お前も同意してたじゃないか）
これは請求キャンセルにも然るべく許可条件をしつらえてやらねばならないと思われる。あーやり直しだ。
