« 「動作確認済モデル」でアジャイル開発 | トップページ | メニューは「権限のインタフェース」である »

2011.02.28

残高テーブルの設計と統計処理

 買掛残高、売掛残高、在庫残高といった「残高テーブル」の構成に関して見る。とくに、残高テーブルと「統計情報」との関係について検討したい。

 以前に取り上げた「取引実績テーブル」もそうなのだが、業務システムにとってごく基本的なテーブルであるにもかかわらず、どのように設計すべきかの議論がきわめて少ない。経理まわりの知識は書籍やサイトで豊富に手に入るが、これをDB設計の問題と関連させた記事がほんとうに少ない。こんな粗末なエントリーでも、ないよりはマシに違いない。

 まず買掛残高テーブルと売掛残高テーブルを見よう。基本的に次のような形をとる。取引先テーブルは「マスター管理サブシステム」に、仕入先テーブルは「買掛管理サブシステム」に、得意先テーブルは「売掛管理サブシステム」に所属する。仕入先と得意先は、取引先の拡張属性を保持する「サブタイプ」として位置づけられる。

┌+取引先 {取引先C} 名称,所在地,...
│         0001 A社 ...
│         0002 B社 ...

├○+仕入先 {仕入先C} 支払サイト,...,現買掛残,...
│          0001     60 ...      0 ...

└○+得意先 {得意先C} 入金サイト,...,現売掛残,...
            0002     30 ...   200,000 ...

 現買掛残高や支払サイトは仕入先Cに関数従属するし、現売掛残高や入金サイトも得意先Cに関数従属する。ゆえにこれらのマスターが掛残高を保持する場所になり得る。仕入計上や売上計上が起こるたびに、取引額にしたがって掛残高が更新されることになる。マスター系テーブルが頻繁に更新されることを避けるために、残高テーブルを別途設ける場合もある。

 売掛を例にして、もう少し詳しく見よう。モデル上の「現売掛残高」は次の式で導出される。

 現売掛残高=期首売掛残高+期間売上額-期間回収額

 つまりこの「現売掛残高」は固有属性ではなく、導出属性(加工データ)なのである。さらに「期間売上額」と「期間回収額」も、期間内の売上実績データを集計して得られる導出属性である。この中では「期首売掛残高」だけが固有属性で、これ以外は本来テーブル上に物理フィールドとしては置かれる必要はない。

 現売掛残高の算出手順は次のとおり。

1.期首売掛残高の値を残高テーブルから読み出す
2.期間内の取引実績データを読み出して、期間売上額と期間回収額を集計する
3.期首売掛残高に期間売上額を加算し期間回収額を減額して、現売掛残高とする

 ただし、実際の案件でこのように実装することは少ない。実際は、期間売上額と期間回収額までを固有属性としてしまう。そのうえで、取引実績が発生するたびに、残高テーブル上のそれらの項目を更新するのである。結果的に、現売掛残高の算出手順2をスキップできる。

 80年代あたりまでは、売掛・買掛・在庫の現残高は、取引実績を夜間バッチで集計して得られるものだったが、今では取引が登録されるそばから変動がわかるように実装される。それだけコンピュータの性能が高まったということで、さらに高まれば、期間売上額と期間回収額をあくまでも導出属性として、オンデマンドで集計されるスタイルになるだろう。論理モデルは実装独立だが、物理モデルについては実装環境の性能等にしたがってこのようにゆらぎ得るのである。

 同様に、期首売掛残高をあえて置かずに、得意先との取引が始まった時点以降の取引実績を集計して現売掛残高を得るやり方をとっても間違いではない。しかし、どのみち決算処理において残高繰越がなされることから、期首売掛残高は管理項目として必須と考えてよい。

 そういうわけで、一般的な買掛・売掛残高テーブルの基本的な物理モデルは次のようになる。カッコ()で囲んだ項目は導出属性である。

仕入先 {仕入先C} 期首買掛残,期間仕入額,期間支払額,(現買掛残),...
        0001     10,000     15,000      0     25,000

得意先 {得意先C} 期首売掛残,期間売上額,期間回収額,(現売掛残),...
        0002     30,000    20,000    30,000     20,000

 商品在庫についてもざっと見ておこう。倉庫別、ロット別に在庫管理するのであれば、次のようになる。「在庫高」と書いたが、ここでは在庫数と在庫額のことと理解してほしい。なお、商品のレベルに全社在庫高を置いてもいいのだが、日常的には必要とされないので、倉庫別と倉庫ロット別の在庫だけを管理できるようにしている。なお、商品の一次識別子が「商品id」となっているが、これはユーザには見えない内部的な識別子と考えたほうがいい。パネル上では二次識別子として設けられている「品番」等で識別できるようにしたほうが、ユーザには使いやすい。

商品 {商品id} 品名,仕様,...


└―∈倉庫在庫 {商品id,倉庫C} 期首在庫高,
   +             期間出庫高,期間入庫高,(現在庫高),...
   │
   └―∈ロット在庫 {商品id,倉庫C,ロットid} 期首在庫高,
                   期間出庫高,期間入庫高,(現在庫高),...

 これらの残高テーブルで売掛・買掛・在庫の残高管理はできる。しかし、会計処理の元ネタとしてはじゅうぶんではなく、統計データ管理用のサブシステムが別途必要だ。たとえば次のような月次サマリテーブルが用意され、定時やオンデマンドで取引実績にもとづいて集計される。

商品別月次サマリ {商品id,年月} 月初在庫額,月間出荷額,
                    月間返品額,月間粗利額,...
 
営業担当別月次サマリ {営業担当C,年月} 月間売上額,月間値引額,
                          月間粗利額,...
 
得意先別月次サマリ {得意先C,年月} 月初売掛残高,月間売上額,
               月間相殺額,月間雑損益振替額,
               月間現金回収額,月間手形回収額,
               (月末売掛残高),月間値引額,月間粗利額,...
 
得意先別月次サマリ {仕入先C,年月} 月初買掛残高,月間仕入額,
                月間相殺額,月間売上原価振替額,
                月間現金支払額,月間手形支払額,
                (月末買掛残高),...

 月次サマリには、残高テーブルよりも多彩な項目が載っている。これらの統計情報が会計処理の基礎になるのである。

 ここで重要なのは、上述した残高テーブルには、こまごまとした統計情報を置く必要がないということだ。せいぜい「期間売上額」と「期間回収額」のように、増額分と減額分のペアを置けば日常的な残高管理はまかなえる。それら以上にこまごまとした統計情報を置けば、残高管理サブシステムの仕様が不必要に複雑化してしまう。ここでも「必要なら載せる。必要でないなら載せない」の設計方針が生きている。また、「複合主キー」があたりまえのように求められる点にも注意したい。

<過去の関連記事>
スタンプ属性や更新履歴テーブルの無駄っぽさ
「複合キー」と実装用フレームワーク

|

« 「動作確認済モデル」でアジャイル開発 | トップページ | メニューは「権限のインタフェース」である »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 残高テーブルの設計と統計処理:

« 「動作確認済モデル」でアジャイル開発 | トップページ | メニューは「権限のインタフェース」である »