締め処理をデータベース上で表現するには

Question

【業務】
・納品書を元に、日々仕入データを入力している。
・月初に仕入先から請求書が来る。（月末締め）
・仕入データと請求書の金額突合せが完了したら、前月分を（変更できないように）締め処理したい。

以下の案１と２はどちらがよいのでしょうか？
それともケースバイケースでしょうか？

【案１】仕入データのカラムとして締め処理フラグを管理する
仕入日付 商品コード 仕入先コード 数量 単価 締め処理フラグ ・・・

【案２】別テーブル（締め処理テーブル）に持たせる
締め対象年月 仕入先コード ・・・

案１は冗長な気がしますが、プログラムはすっきりします。

Answer 1

こんにちは。

他の状況をもっと知らないと、どっちがいいとは言えないのですが、
自分が同じ選択肢で悩み、多少工数に余裕があるのなら
【案２】
のほうを押す方向で考えると思います。

なぜかというと、今後、

• 締めを行ったユーザーが誰なのかを分かるようにして欲しい。
• いったん締めたものを差し戻して伝票内容を変更し、再度締めができるようにして欲しい。
• その際にも差し戻し処理や、再度の締めをしたユーザーとその日時も分かるようにして欲しい。

といった要望が業務側から出てきそうですし、逆に要望が出てこない
のなら、これらを提案することが可能だからです。

【案１】だと、このように「締め」に様々な属性を持たせるということに
対応するのが大変になりそう（＝仕入れテーブルに「締め」の情報がどん
どん増えて巨大なテーブルになる）な予感がするのですが、【案２】だと、
業務システムとして、「締め」あるいは「締めるという業務」を、「仕入れ」
とは別の１つのエンティティ（または、モデル）として扱うことを、
（複数の開発者がいるのでしたら、チームの認識としても、）
はっきりさせることができます。
また、ある「仕入れ」にひもづく「締めの履歴」をリストすることで、
業務の改善が図れるという状況があるならば、迷わず【案２】です。

とはいえ、「締め」機能のリリースまでにどれくらいの工数をもらえるのか
にもよります。【案２】だとテーブル１個増やすので、それに対するモデル
やロジック、必要ならばビューもと、新しくひと揃え書くことになり、
ひと手間かかりそうですからね。

最近は、業務システムもアジャイルを取り入れることが多いと聞きますが、
冒頭に上げたような追加要件が必ず発生するとはいえないという状況ならば、
「気を回しすぎて、アレもコレも盛り込む」というのは、「想定できる機能
を全部は作らない」というアジャイルの方針に反することにもなります。
（※「想定できる機能を全部は作らない」のがアジャイルだというのは、
単なる私見です。すみません。そういう主張をどこかのブログか記事で
読んだだけなのですが、けっこう納得したので。）

と、いろいろ考えるべきファクターがありそうなのですが、私なら
どうするかというと、こうします。

【案１】と【案２】で迷っていて、【案１】だとほぼ瞬殺で終わるけど、
【案２】だとこれだけ時間がかかる。ただここで多少時間かけてでも
【案２】で設計、開発したら、今後「締め」に対する業務からの色々な要望に応えられる。
色々な要望として想像しているのは・・・の時や・・・の場合、とかとか。

という相談を、業務側の担当者に持ちかけます。そうすると、結果的に【案１】で
やることになったとしても、業務側から、
「◯◯さんはただ作るだけじゃなくていろいろ業務よりのことも考えてくれて頼もしい」
的な評判を得ることができたりするのです。老獪かもしれないですが、業務側からの
そういう評判、業務システムの開発やるときには大事だったりするもので。

思いつくのは、以上です。
参考になれば幸いです。

Comments

[jk233]

ありがとうございます。
案２を採用するメリットが明確になりました。
業務に相談できるレベルに落としこんでみます。

[jun68ykt]

こんにちは。ご返信ありがとうございます。うまくいくといいですね！Good luck をお祈りします。

Answer 2

こんにちは。

締め処理があるということはおそらく締め日があると思います。
仕入入力があるということは仕入れ日（納品日？）があると思います。

締め処理データ（○月○日までは締められたというデータ）を保存し、
過去納品日の仕入れデータを編集する場合は、プログラムで編集処理を開始する前に締め日と仕入れ日を比較して編集可能か不要か判断しては如何でしょうか。

フラグだと二重管理気味になってしまいますし、
締め日で判断すれば締め処理の解除などの機能が必要になった場合も締め処理レコードを削除すれば済みます。

Answer 3

私は、フラグではなく、売上、仕入データに、締日、または、請求書番号を入れるようにしています。
そうすれば、締め直し、締め後日付での入力（やめてほしいけど、顧客がわがままだと、対応せざるを得ないときがあります）などのイレギュラ処理にも対応可能です。
別テーブルだと、そういったイレギュラな処理を、安全に対応することが難しくなります。

Comments

[jk233]

ありがとうございます。
案１を採用する場合はフラグではなく締日を設定しようと思います。

[kantomi]

実はハイブリッドです。
仕入の場合、仕入締めテーブルを持ち、仕入テーブルにフラグではなく、締日、または仕入締めテーブルのキー（締め番号）を持ちます。
請求などの締めも同じ。

仕入データからも、いつ締め予定のデータが、いつ締められたか分かるようにしておかないと、大きくなれば後の調査に苦労します。
更に、例えば、個別締め（20締めだけれど、今月は決算なので末でいったん占めて欲しい）などという要望にも対応できます。