« コード設計の固定観念 | メイン | 汎用的データベース設計とは? »

集計コードの考え方

今日は9月30日。

我がアイロベックスの期末日になります。

いつも夏になると必ずお客さまのところに「最後のお願い」をして回るのが通例になってしまっています。

来期こそは、余裕で決算を迎えたいと毎年思います。

何かと色々ありましたが、皆様のおかげで決算を迎えることができました。

本当に心よりお礼を申し上げます。

さて、システムでも「締め」の感覚は非常に大事なものです。

このところ、コードの話を長々と続けてまいりましたが、期首から期末、半期といった締期間とコードの関係を考えてみましょう。

取引先コードや商品コードといったものは、締期間とは密接には関係していません。

問題になるのは、部署コード、担当者コード、分類コードといったものでしょうか。

例えば、営業担当者別に受注実績月報を集計して出力するシステムがあったとします。

営業は部が2つで、課はそれぞれ3つずつあるとします。

営業担当者の実績明細が出て、課が変わるごとに課の合計を出力し、部が変わるときに部の合計を出力するとします。

また、営業担当者マスタの中に部署コードが登録されていると仮定し、年月、担当者コードが主キーとなる実績ファイルを使います。

ここで、このような営業担当者マスタを「A」とします。

営業担当者は帰社時間がまちまちで、直帰することもあったりするため、全員の情報を締めて集計表を出すのは、翌月の営業日3日目になるとします。

すると、3月31日の集計表を出すのは4月3日になります。

ここで、4月から新しい期がはじまり、営業担当者の異動があったとします。

営業担当者を課別に並べた場合、4月3日に印刷すると、新しい期の組織で印刷されてしまうことになります。

これは困ると思います。

考えられるのは、担当者マスタに登録されている課を、システムの締め処理を済ませてから修正する方法でしょうか。

しかし、新しい組織は3月の始めに決まっているのに、4月3日まで修正できないというのも良い方法とは思えません。

ましてや4月1日から4月3日までは、課別・担当者別といった帳票は、すべて前期のものでしか確認できないことになります。

そこで、現在のシステムでは、担当者マスタの中に部署コードを登録することはやめて、異動年月日および担当者を主キーにしたテーブルを持って、そこに部署コードを登録する方法をとるのです。

ここで、このようなテーブルを「B」とします。

そうすれば、Xさんが平成19年3月31日までは営業第一部A課であり、4月1日からは営業第二部B課となっても問題は無いのです。

どちらの日付締めの考え方で帳票を印刷するかをユーザーが指定すれば良いだけなのです。

この場合の問題は、データベース設計で回避できるわけです。

しかし、年月が主キーに含まれている実績ファイルが作成されておらず、売上明細を日付で集計して部署別・担当者別に集計表を出そうと思っている場合はどうでしょうか。

この場合、売上明細の中に含まれているのが担当者コードだけで、部署コードが含まれていないのであれば、そう問題はありません。

しかし、売上明細の中に担当者コードと部署コードが含まれてしまっている場合、つまり、「売上入力」のような、売上明細を作成登録するエントリプログラムが、入力時点の担当者マスタをチェックして、そこに含まれている部署コードを登録しているのです。

組織替えの日付に前もってテーブルBが新しい部署で登録されていれば問題無いのですが、登録すべき総務部が忙しさにかまけて登録し忘れていた、などといった場合、エントリでエラーが出てしまいます。

また、そうでなければ、新しい期の情報登録なのに、前期の部署情報で登録されるということが起こりがちです。

また、部と課の関係が複雑に分裂、異動するような場合には、過去の情報に遡ってコードを付け直すことも必要になってくるでしょう。

コードと一口で言いますが、集計分類に使うコードは、こういった締め期間ごとに登録できたり、付け替えたりすることができるようにも設計する必要があるのです。

Vol.00162

トラックバック

このエントリーのトラックバックURL:
http://www.ilovex.co.jp/scripts/intra/mt/mt-tb.cgi/2681

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2008年09月29日 11:30に投稿されたエントリーのページです。

ひとつ前の投稿は「コード設計の固定観念」です。

次の投稿は「汎用的データベース設計とは?」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.38