CONCEPTWARE財務管理を添削する 1/2

(2006.1.1新規作成; 2007.10.10 内容を加筆し、ページを分割。)

会計システムは、企業ごとの差が出にくい部分なので、システムを導入するときにパッケージを選ぶ企業・団体が大半だと思います。

2005.11.27, 2005.12.4 のように、「MJSLINK財務大将EX」なるソフトで詐欺商法にあってしまいました。日々、あらゆる想定を超越する驚きのソフトなのですが。

それはどうでもいいですが、では、企業における会計システムにはどのような機能が必要か、公開されているモデリングデータ「CONCEPTWARE/財務管理」を題材にして考えてみます。

企業における会計システム

(2006.7.21 この節更新。)

会計システムと一口に言っても、企業で使うための会計システムと、会計事務所で使うための会計システムは、その要求範囲が大きく違います。

会計事務所の会計システムは、(1) 会社で保管する領収証、請求書、銀行に対する振込依頼書などの証憑にもとづいて、(2) 勘定科目ごとに取引金額を整理して、(3) 試算表・決算書を出力し、(4) 納税のための基礎資料を提供する、という辺りが処理する範囲になります。

結局、リポーティングが目的であり、しかも、納税のための会社全体の収支計算が行えれば十分です。

総勘定元帳

企業で必要とされる会計システムは、これより範囲がぐっと広がります。リポーティングの部分についても、部門単位で把握できる必要があります。また、これらの部門単位、あるいは勘定科目単位での集計を整形し、経営陣、部門長など必要な人まで届ける必要があります。

OLAPの知見を踏まえると、部門、販売チャネル、社員、取引先、勘定科目といったディメンション (dimension) ごとの金額を把握できるようにすればいい。メジャー (measure) は実績、予算などになるでしょう。

実績は一つですが、予算は定期的(通常は半年ごと)に見直しがあります。

これらは結局、総勘定元帳 (G/L, general ledger) が担うべき機能です。

APおよびAR

しかし、これだけにとどまらず、企業における会計システムは、購買プロセスと販売プロセスの終端の部分を担えなければなりません。


(出典:あずさ監査法人 | 日本における内部統制制度の現状(1)財務諸表に係る内部統制基準化への動向と文書化について Page3

購買プロセスは、発注→検収→支払いというプロセスを経ますが、このそれぞれの過程で適切にG/Lにデータを流し込むほか、経理・財務部門は業務として支払いを担当します。具体的には、銀行振り込みを実行し、現金払い、自動引き落としの記録を処理します。仕入先に対する債務を管理する必要もあります。

同様に、販売プロセスでは、受注→提供→回収というプロセスのうち、販売先に対する債権の残高を管理(継続記録)し、また、回収結果を記録する部分を担当します。決算のときには残高確認を取引先と相互におこないます。

総勘定元帳 (G/L) は、勘定科目、部門などで集計された金額データなので、本質的にかなり要約された状態でしか処理しません。しかも、金額データでないものを処理するのも苦手です。そのため、購買システム、販売システムに詳細データを持ち、総勘定元帳はリポーティングのための結果データだけを持つようにするのが妥当です。

締め日

会計システムの本質的な特徴として、締め処理があります。毎月おおむね翌10日ぐらいまでに取締役会へ月間の収支データを報告します(月次決算)。その報告データを固めたら、過去のデータを触れないように締め処理を行います。

この段階では見積もり計算もあり、また後から誤りが発見されることもあります。しかしそれらは次月に修正します。購買データの修正を行う場合であっても、会計システムには次月に反映させます。

主に実務の要請ですが、どこから見切りをつけないといつまでも決算を確定できません。また、遡及修正をすると、月次報告を12ヶ月足したものが年度の数字になりません。

もっともこの発想は、日本の会計基準では本決算でも基本的に遡及修正は行わないことからきているかもしれません。(IFRS/IASでは会計方針の変更、誤謬などで遡及修正を行い、過年度情報をrestateする。)

CONCEPTWARE/財務管理

「CONCEPTWARE/財務管理」は、卸売業向けの財務会計システムのデータモデリング、スケッチ図として、無償で公開されています。

同じく無償で公開されているXEAD用のデータになっています。

これだけの分量のものを公開されているのは素晴らしいと思います。以下では、このモデルが実際に適用できるのかどうかを吟味してみようと思います。

試したCONCEPTWARE/財務管理のバージョンは、バージョン1.1.2 です。一部、バージョン1.0.01 (2005-08-30) のときの文章もあります。

結論から言えば、議論の余地のあるところがあり、このまま実装してはダメで、だいぶ手を入れないといけません。

前提条件

(2007.10.7)

CONCEPTWARE/財務管理では、次の前提条件が挙げてあります。

  • 売上高が10億円程度以上の専門卸売業向けであること
  • 外貨取引はないこと
  • 本支店間取引はないこと
  • 手形は売上受領・仕入支払のみに利用され、売上以外の一般収益の受領や諸経費の支払には利用されないこと

会計システムには、基本的に、業種ごとの差異というものはありませんが、卸売業向けとは何でしょう。もちろん、購買プロセス、販売プロセス、商品・材料管理、生産のほうまでを考えると違いが出てきます。

本支店間取引とは、この文脈では、何を指しているんでしょうか。手形を売上・仕入に限定する理由は何でしょうか。

一見、この辺りが気になります。

AB 共通リソース管理

(2007.10.7 更新。)

まずは、マスタ関係のテーブルや画面を見て、システムがどこまでカバーしようとしているか確認してみましょう。

企業・団体における会計システムには、

  • 勘定科目マスタ、会計部門マスタ
  • 社員マスタ、組織マスタ
  • 取引先マスタ
などが必要です。これらのマスタのうち一部は、人事システム、購買システム、販売システム、生産システムなどと共有します。

CONCEPTWARE/財務管理では、共通リソースとして、以下のテーブルをデザインしています。

  • 部門
  • 従業員
  • 従業員配属明細
  • 従業員職種明細
  • 取引先
  • 得意先属性
  • 出荷先
  • 仕入先属性
  • 業者属性
  • 銀行
  • 消費税率

順番に見ていきましょう。

ABT010部門

(2007.10.7 更新。)

会計部門を表すテーブル。部門名、部門レベルのほか、事業所コード、上位部門コード、部門管理者コードを持っています。部門管理者はその会計部門の責任者のことでしょうか。

このデザインだと部門がただ一つの上位部門を持つようになっていますが、これでは不味いです。会計部門は、事業別と地域別、あるいは予算実績管理のための部門木と地域別、など、複数の木が作れなければいけません。

集計部門テーブルを用意して、多対多で繋ぐといいと思います。

事業所コードのフィールドがありますが、会計部門と事業所が関連付けられない場合も多いので、ナルが多くなります。そもそも部門から事業所を紐付けるうれしさが分かりません。集計部門があれば十分でしょう。

ABT020従業員

(2007.10.7 更新。)

社員を表すテーブル。氏名、雇用区分、パスワード、メールアドレス、あと給与口座、立替精算(小口精算)口座の属性があります。

銀行口座というものは、(銀行、支店、口座種別、口座番号、カナ名) で1セットなので、この属性では振込みできない、というのはまぁ置いておくとしても、このシステム、小口精算までカバーしていますか?

小口精算は、セルフ精算にしないとシステム化する意味が乏しいですが、セルフ精算はワークフローが本質なので、そちらの機能が必要です。

一応ここでは、振込口座名が必要、という指摘に留めます。

従業員配属明細、従業員職種明細テーブルは、別に、会計システムには必要ないんじゃないでしょうか。後者はシステムでのroleを表すわけでもなさそう。

ABT110取引先ほか

(2007.10.7 更新。)

ABT110取引先が基底クラスで、ABT120得意先属性, ABT130仕入先属性, ABT140業者属性が派生クラスになっています。P of EAA の Class Table Inheritance (CTI) パターンを適用した形。取引先テーブルとそれ以外のテーブルは1対1です。

ActiveRecordに載せようと思ったら一つにまとめることになりそうです。

このテーブルのデザインは相当おかしいです。

ある取引先は、仕入先になることもあれば販売先になることもあります。だから、共通テーブルを設けて、仕入先、販売先にしかないフィールドを別テーブルにするのはいい。

しかし、ABT140業者属性は何のためにありますか? というのも、売掛先、買掛先としての得意先属性テーブル、仕入先属性テーブルはすでにあります。例えば、支払う、という行為については、財務部門ではそれが商品仕入先かそうでないかの区別を要しません。

取引先テーブルに振込先銀行口座があるのもおかしいです。これは仕入先の属性とすべきで、さらに1社が複数の口座を持つことがあることの考慮が抜けています。

振込銀行口座のフィールドは、またもや口座名義フィールド(カナ)がありません。振り込めません。

得意先属性、仕入先属性テーブルに担当者があるのも、慎重に判断する必要があります。

ここは、全面的に作り直して、

  • テーブルを取引先、得意先属性、仕入先属性に整理する。あるいは一つの取引先テーブルにする。
  • 振込先口座テーブルを設ける。取引先と1対多の関係。
  • 連絡先テーブル contacts を用意する。後で出てくる出荷先テーブルとの関係は考える必要があります。
  • 取引条件の取決めテーブル agreements を用意する。取引先テーブルとは多対多か。

出荷先

得意先の事業所を登録します。ところで、自社の倉庫マスタはあるでしょうか。

ABT150銀行

国内の銀行を表します。実際にはCD-ROMなどから流し込むことになるでしょう。

銀行コードを7桁で持っていますが、普通は、銀行テーブルと銀行支店テーブルに分けて、4桁+3桁にします。

所在地、電話番号、FAX番号、摘要フィールドがありますが、一体何に使うのでしょうか。自社から振込む先の銀行に用事はありません。

自社の口座がある銀行の住所などは、残高確認のときに使うことがあります。残高確認依頼状を発行するようにして、自社取引銀行の住所などを登録するのは悪くないアイディアだと思います。

次のようにします。

  • 銀行マスタからは不要なフィールドを削除
  • 自社の銀行口座テーブルを用意 --- (2007.10.11) AFT010現預金口座テーブルがこれみたいです。

消費税率

何だか唐突ですが、消費税率を表します。

消費税率、地方消費税率を別々に登録するようになっていますが、アホですか。一度でも消費税申告書を見たことがあれば、こんなトンマなことにはならないと思います。

AC 仕訳データ管理

会計システムで大切な勘定科目マスタはこの区分に分類されています。仕訳テーブルもこの区分に分類されています。

ACT100勘定科目

[勘定グループ] フィールドは、00=流動資産、01=土地・建物、・・・20=資本金、・・・としていますが、大項目すら会計基準・法令の改正で気まぐれに変わるので、決め打ちは不味いです。というか区分のセンスが悪い。

部門と同様、勘定科目木を複数セット持てるようにすべきです。実用上、各科目にはデフォルト消費税区分がほしい。

仕訳見出し、仕訳明細

仕訳データは、日付などは見出しテーブルへ、金額は明細テーブルへ分ける方式です。

テーブル名は仕訳明細ですが、借方、貸方を持つのではなく、(科目, 金額) を1セットしか持たないので、これが総勘定元帳になります。

消費税をセットするフィールドがありませんが、仮払消費税、仮受消費税を明示的に立てる方式でしょうか。総勘定元帳に消費税フィールドを用意して、必要に応じて税込みでも税抜きでも表示できるようにしたほうが便利です。

仕訳制御

勘定科目の設定を格納するテーブルです。「受取手形」科目のコードなどを格納します。システムはこれらのテーブルを参照し、実際の勘定科目にアクセスします。

業務プロセス

マスタ系について大体見たので、次は業務プロセスを意識しつつ、トランザクション系について見ていきます。

(2007.11.15) 長くなったので、ページを分けました; ページ2

外部リンク