請求締め処理に際しての他処理へのロック: - 六の日記はこっちになったぞ

普段こんなメモ書かずに頭で考えてちょちょいのちょいでやるんだが、ちょっとメモってみよう。

　請求締め後、その請求期間内を計上日とした売上計上、売上計上訂正（削除も含む）、入金登録は、請求書に全く載らなくなるため、これを禁止する。
　いくつか深く考えずにつらつらと。現状把握もふまえつつ。

　さて、何故に稼動後3年を経て問題が顕在化したかと云うと、経理の人がやめちゃったり新人が入ったりで、大幅に人事が変わったから。

　これまでの債権担当、仕入関連債務担当、経費関連債務担当って美しい人員配置（ほぼシングルユーザーと思って間違いなかった）が崩れて、請求締め係と入金登録係が別の人になっちゃんたんだなあこれが。遺憾。急いで作るとろくな事が無い。設計は俺じゃないんだけどね。

請求締め処理の前段階で、請求締め対象となった取引先に対して更新する。
処理順序は

以上を締め処理対象の取引先全てにやるわけよ。数百件ってところか。
これなら締め処理中でも最新締め日でロックがかけられる。締め日更新中にやられたらどうなのよって話はもうこの際、度外視。そんな時間はかかるまいて。

長所
- カラム追加だけでテーブル構成の変更がない。
短所
- 以下の運用で、元の締め日をどっからとってくるのって話になる。
  - 請求キャンセル
  - 請求締め処理が途中でコケた時のお掃除
- 蓄積された請求データ（コケた場合は勿論ロールバック後）からMAX値を取るしかないが、パフォーマンスにかなり不安がある。

　キャンセル時などで元の締め日に戻すんだったらこの手はどうか。
　会計締め日に関しては、カレンダーテーブルで計上日の可否をコントロールするが、それと同様の機能・テーブルを請求締めにも用いる。つまり、上記取引先毎の最新請求締め日を管理するテーブルを作る。

長所
- そりゃもう、それ専門のテーブルですから、レスポンスはいいでしょう。
- 最新締め日更新時、履歴管理すればキャンセル対応も効く。
短所
- 管理が面倒くさい。今からじゃコストかかる。
- 履歴管理すると、とってもふくれる。取引先マスタの全件数を見よ。
- 取引先単位じゃなくて、締め日単位でやればどうかって話になると、入金時等の入力チェックで、まず当該取引先の締め日を取得して、計上日の年月とくっつけて、そんで締め済みかチェック、とか
- ああ駄目じゃん、そもそも請求締め自体、やろうと思えば取引先単位で出来るんだ。キャンセルも出来るし、勿論キャンセルしたものを再び締める事も出来る。その時々でチェック条件が変化しないといけない。がー。

　取引先マスタに最新請求締め日を持つのが一番ナイスと思う。請求キャンセル時の元の締め日は、請求データ全体からMAXを取るしかないが、キャンセル発生の頻度からするとそうシビアにレスポンスを考える必要も無いだろう。

　実際現在の売上計上、入金登録の計上日チェックで最新締め日を請求データから取ってる訳だし。

　大体テーブル一個追加なんてもうやりたくないし、履歴管理したら結局請求の数と同じだけ出来る訳で、実にバカバカしい。

　あー最初からちゃんと考えて設計してればなあ。

　何故にこんな簡単な解決法に辿り着くのに、バカなテーブル作ろうかとか考える程に慎重なのかと云うと、リソースとして扱われるデータ対して、斯様なトランザクションデータを持ち込むのはどうも気持ちが悪いからだ。

　商品マスタの原価管理などは例外として見れるんだが、マスタに流動的な属性を持たせるのにはどうしても抵抗がある。

　がしかし、その抵抗を感じつつ導入するのであれば、「俺って判ってるぜフフン」とか陶酔出来つつも実運用がスムーズに、と云う素晴らしい結果になるので此処は良しとしよう。

　やらないよ多分。単に、未来の案件のためにその一だ。