GW明けから黙々と作っております、弊社の新しい販売管理システムがいい感じに仕上がりました。３連休明けに社内運用が開始出来ると思います。ﾌｩｰﾌｩｰ。
で、個人的にこれがポイントかなって思うことをメモっておきます。
1. なにはなくとも、DB設計
やっぱDB設計ですよ。正解は無いけど、はずれは絶対あるから。気をつけるのはカラムの中に意味を持つタイプのデータ。削除フラグとかそういうの。ON/OFFレベルのフラグはあってもいい。そのテーブルの中でしか使わないのなら、まぁたいしたことが無い。けど、1がアレで２がそれで９がどれみたいなのは、あかん。何かのアクションを求められる情報をカラムに格納するのはあまりオヌヌメできない。僕の今回のシステムでは１カ所だけそれが必要だったけど、後は無かった。今現在。
2. 世の中CRUDで出来ている
受注も発注も出荷も入庫も売上も支払も、各々新規作成／訂正／削除／検索というものがあります。訂正と削除は結構お悩みポイントで、ドコまで戻すのかとか、削除したら他のテーブルに影響が出るかとか、訂正させない状況が必要なのかとか、その辺の考慮がポイントになります。例えば締め処理を行った納品伝票の訂正は出来ないとか。もちろん削除も出来ない。発注したあとの受注は訂正出来るのか、とか。削除したらどうなるのとか。顧客を削除するとFKで紐づいてる皆さんはどうなるのか、とか。全てのオブジェクトにCRUDがあると考えれば、自ずと仕様が洗練される。
3. 入力系の画面からつくる
いきなり検索画面作るヤツいないよね。入力が決まらないのに出力考える必要ないよね。大丈夫だよね。
入力系の画面ってのは様々なバリデーション／入力補助が必要になり、たいていその補助は他の画面でも大いに活用するので、そこだけ抜き出して使えるようにしておきたい。つまり、イベントが発生する場所は変わるけど、やることは変わらない or 微妙に変わる。なので、イベント発生に対して行う処理はイベントハンドラを自由に選べるように、C＃で言うと、デリゲート出来るようにするといい。ここをif/elseでハンドルすると「この画面だったら」とか「この項目とこの項目だったら」とか、いかにも修正漏れがでそうな分岐が生まれるので気をつけたい。
4. データのターンアラウンドを意識する
この記事に詳しい。
ERPのもう1つの本質は、「データのターンアラウンド」です。例えば「販売管理」で受けた注文を製造指図として「生産管理」に連携し、製造に必要な資材を「調達管理」で調達、生産された製品を「在庫管理」で管理し、そして「販売管理」で出荷・売上するといったように、それぞれの業務が連携しています。そして販売や調達によって生じた取引は「債権管理」や「債務管理」で管理され、入金や支払などの実績は会計に連携します。
第1回 ERPの概要と導入のポイント | Think IT
全てのデータは顧客と商品を中心に、色んな顔を見せます。受注したら発注がいるし、発注が入庫に、入庫が仕入れに仕入れが支払いに・・・という感じ。つまりテーブルのプロパティでかぶる部分が相当あるから、コピー出来る設計を意識すると良いっていうかBeanUtils.Populate(src,dest)ですね。要は。発注をコピーして仕入にあげるとか基本的な機能だけど、意外と無かったりする。
5. 全角半角とかそんなのサーバーサイドで空気嫁
意外と抜けるのが、バイト数チェック。伝票には印字領域があるので。品名や顧客名はバイト数チェックが必要です。相関チェックも忘れずに。Aが変更されたらBに影響があるものは、チェックしてユーザーにお知らせすると親切よね。
6. 処理の内容を動的に変更する
受注明細と発注明細の登録で何が違うかと言えば、在庫の引き落としの有無。発注するのに在庫引くことはない。だから、その在庫を引くっていう処理を外から与えてやる。オーバーライドなのかクロージャなのかは議論があるだろうけど、オーバーライドで空Returnでもクロージャでその時用の関数を作って返してもいい。発注なら在庫引かないとかこのキーが入ってるとアレみたいな処理をif/elseに埋め込むとロクなことが無い。
7. ifを通していいのは１つの条件だけ
なるべくこうしたほうがいいというレベルなんですが、僕は複合条件でifを書くのが嫌いなのでなるべく排除してます。通していいのは１個の条件のみってのを心がけると基本的にYES or Noだけになるのでシンプルになる。在庫が０で予約受付の商品なら・・・みたいなIFを気軽に書くと在庫が０だけど廃盤なら通知をあげる、みたいなヤツが増えたりして、色々辛くなります。
こんなところです。
