ERPの落とし穴part1～SW開発ではない。要求開発だ！の続き。
「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)
」を非常に参考にしているので、全てが僕のオリジナルの考えではないので注意。
【1】業務の裏には会計あり。業務データは必ず仕訳データに連携される。
業務システムの裏には必ず会計システムがある。
Webで作っていても、メインフレームで動く会計システムと連携できなければ、ただの箱に過ぎない。
会計システムと連動できて初めて、業務コストや売上が計算出来るし、更には売掛金管理や請求管理で経理担当者の仕事もサポートできる。
例えば、「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、販売業務では、受注→出荷→売上→請求→入金のような業務フローがあるだろう。
業務データの裏には、仕訳データと連動している。
普通はお金のやり取りが発生したタイミングで仕訳が発生するから、売上処理で「売掛金//売上」、入金処理で「当座預金//売掛金」という仕訳が発生しているだろう。
業務SEは、この流れを理解しているから、業務分析ができるのだ。
この流れがスラスラと出なければ、業務SEとは呼べない。
仕訳の知識が必要な理由は、業務には例外処理や訂正処理が非常に多いからだ。
「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、「商品の返品は売上高のマイナスになる」「請求に対して過入金があった場合、売掛金のマイナスで処理される」例がある。
前者の仕訳は「売上//当座預金(又は現金)」という逆仕訳が発生する。
後者の仕訳は「当座預金//仮受金、売掛金」という仕訳で、仮受金と言う内容が不明な入金があった負債勘定科目を当てる。
このように、売り上げた(又は仕入れた)商品の返品や値引き、入金の過不足対応などの例外処理の業務に対応するだけでなく、仕訳データも連携しておく必要がある。
ERPでは、会計システム連動の機能は、普通は、自動仕訳と言う仕組みでIT化されているのが普通だろう。
つまり、業務データに対し、仕訳データのパターンは決まっているので、仕訳パターンに従って仕訳を自動で起こし、会計システムへ流す。
仕訳パターンはあらかじめDBに登録しておいてもいいし、経理担当者がWebのUIから入力できるようにしておけばいい。
「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、自動仕訳のパターンの例があげられている。
すべて覚えても良いぐらいだ。
仕入： 仕入//買掛金、仮払消費税
仕入返品 ：買掛金//仕入値引、仮払消費税
売上： 売掛金//売上、仮受消費税
売上返品： 売上値引//売上、仮受消費税
入金(改修消し込みと別)： 当座預金//仮受金
回収(入金あり)： 仮受金//売掛金
回収(入金と同時処理)： 当座預金//売掛金
回収(消費税端数不足)： 当座預金//売掛金、雑損
回収(振込手数料差し引き)： 当座預金//売掛金、支払手数料
回収(加入金)： 当座預金//売掛金、仮受金
支払い： 買掛金//当座預金
普通は、企業規模が大きいほど1日のお金の取引は多いので、いわゆるバッチ処理で実装する時が多い。
そのバッチ処理は、PLSQLのようなストアドプロシージャで実装する時が多い。
例えば、毎日深夜にCronで定期的にシェルをキックして、シェルにあるJavaのメインクラスがPLSQLをキックする仕組みが普通だろう。
この仕組で実装しておけば、JavaからPLSQLをキックしているから、PLSQLの単体テストにDBUnitを使えるので、テスト駆動開発もデイリービルドも可能になる。
WebシステムはJavaで、バッチ処理はPLSQLで使い分けるアーキテクチャが多いだろうと思う。
【2】赤黒伝票という訂正仕訳。逆仕訳。
日本特有（？）の会計処理として、売上や入金などに関する仕訳データを修正する場合、赤黒処理を行う。
つまり、直接データを修正するのではなく、黒伝票を赤伝票で相殺して、正しい仕訳を追加する方法を指す。
簿記3級では、訂正仕訳とも呼ばれていて、「まず正しい仕訳をメモしておき、誤った仕訳の次に逆仕訳、その次に正しい仕訳を書く」(正誤逆正)と教わった。
訂正仕訳を使う状況は、職員が勘定科目を間違って仕訳を作った時が多いだろう。
訂正仕訳が必要な理由は、会計情報と言うお金に関する情報は必ず操作履歴を残す必要があるからだ。
コンプライアンス上の理由もあるのだろう。
逆仕訳、訂正仕訳が起きる業務は要件定義や要求のヒヤリングで漏れやすいので、何度もユーザに確認すべき。
要件漏れがあると、そのシステムはユーザにとって非常に使いにくくなる。
【3】締め処理という考え方。支払いサイト、月次締めの違い。
日本特有の請求処理として締め処理という概念がある。
例えば「月末締め翌月末払い」とは、毎月末に売上や仕入の請求を締めて、翌月末に入金や出金を行うことを指す。
つまり、掛取引を締め日と言うタイミングで一括処理するのが日本の商習慣。
日本の会社は基本的に、5日、10日、20日、30日のように5の倍数の日に締め日を指定しているから、銀行は5の倍数の日は非常に忙しい。
給与振込も普通は5の倍数の日が多いだろう。
「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、取引先ごとに締め日を変えたりする複数締め日もあるという。こんな例はまだ見たことがないけれど、要件定義になかったら、受入テストで痛い目にあうだろう。
支払い方法は銀行振込以外にも日本特有の手形取引という手法もあり、手形の振出日から期日までの期間を支払いサイトという。
「月末締め翌月末払い」の例では、支払いサイトは「月末の振出日から30日サイト」になる。
「20日締め翌月末払い」の例は、支払いサイトは「振出日20日から40日サイト」になる。
手形のサイトが長いほど、現金化できる日が伸びるので、受け取る側は貸し倒れリスクも発生する。
「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、古い体質の業界では、大手企業が下請けいじめとして、支払いサイトを120日以上も指定する時もあるという。
支払いサイトの考え方が重要な理由は、売掛金や買掛金処理で重要だからだ。
普通は、ユーザ企業の営業日カレンダーをDBで持っておき、取引先への支払日は支払いサイト情報からPLSQLで自動計算する仕組みになっているだろう。
支払日の計算は単純にサイト日数を足すだけではないのだ。
この締めという概念は、上記のような請求締や支払い締だけではない。
もう一つは月次締という概念がある。
月次締めは、毎月の売上や損益を月次単位で集計するための締めだ。
いわゆる計上日と関連する。
普通の会計システムは、月次締めは仮締めと本締めの2種類がある。
３月末に締め切ったとしても、４月１日に３月上旬の経費の請求書が届く場合もあるし、３月の仕訳に誤った仕訳もあるだろう。
それらの仕訳を入力修正した後、仮締めを実行して何度も集計結果をチェックする。
これでOK、となった時点で、本締めで３月度の売上や損益が確定し、締められた３月の仕訳は入力できなくなる。
だから、３月中の会社の出張旅費や交通費の精算書は、必ず３月末までに経理担当者へ提出しなければ、手元に戻ってこなくなる。
IT化される以前は、経理担当者は３伝票(入金・出金・仕訳伝票)で日々の仕訳を残し、締め日になってから手作業で集計してチェックしていたから、締め日から本締めできる日まで１５日～１ヶ月もかかっていたらしい。
しかし、最近は３伝票のような紙はなくなってIT化されたので、３～５営業日で本締めできるようになった。
その分、月次の売上や損益のデータを経営者へ早くフィードバックできるので、よりスピーディな経営判断ができるようになった流れがある。
締め処理は、国税庁へ提出する会計帳票を作るために非常に重要な概念の一つ。
【4】残管理を業務システムがサポートする。
業務システムを作った場合、残管理という業務支援の使い勝手の良さが顧客満足度を左右する時が多い。
「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」によれば、受注残(受注したが未計上)、未請求残(売り上げたが未請求)、売掛残(請求したが未入金)などの例がある。
つまり、残管理を徹底して、出荷漏れ、請求漏れの防止や未入金顧客への督促などを支援したいのだ。
昨今のように会社倒産が多い場合、売掛残の管理がしっかりしていないと、せっかく売上があっても入金されないと言う悲しい事態が起きやすい。
残管理でよく出る帳票は、買掛金元帳と売掛金元帳。
買掛金元帳は仕入先元帳とも呼ばれ、仕入れたが出金していない買掛残を管理するための帳票。
経費の支払、商品の仕入が相当するだろう。
買掛金元帳は、仕入先単位に毎月の買掛残の詳細と集計を出力し、振込日にいくら支払えばいいか、チェックするために使う。
取引先ごとに支払いサイトを変えて振込する時もあれば、自社の支払サイトに従って全ての取引先へ振り込む場合もある。
銀行振込には振込手数料がかかるから、できるだけ一括払いしたいものだろう。
売掛金元帳は得意先元帳とも呼ばれ、売り上げたが入金回収していない売掛残を管理するための帳票。
商品の売上、サービスの検収などがあげられる。
売掛金元帳も、得意先単位に毎月の売掛残の詳細と集計を出力し、請求書を得意先に送って入金を促す。
最近は得意先の資金繰りも苦しい所が多いので、入金を催促する時が多い。
更に商品の在庫管理も重要だ。
在庫引き当てという処理は、倉庫にある商品を注文単位で予約しておくこと。
だから、リアルタイムに在庫数を表示すること、複数の注文の在庫引き当てが発生した場合、きちんと排他制御ができていることが重要になってくる。
在庫引き当て処理は、どの業務システムの中でも実装もテストも難しい部分。
商品在庫の残高管理も重要だ。
簿記３級では、商品有高帳という補助簿があり、商品単位に仕入と支払を仕訳で記帳して残高を管理する。
残高の計算では、商品の原価を計算する必要があり、原価法として先入先出法と移動平均法が有名だ。
先入先出法は、先に仕入れた商品から先に出していくものとして払出単価を決める。
移動平均法は、商品を異なる単価で仕入れるごとに、平均単価を計算して決める。
情報処理技術者試験でもよく出てくる概念。
いずれもIT化されていば自動計算できるので、リアルタイムに在庫のコストがすぐに計算できる。
【5】株式会社が必要とする会計帳票。主要簿と補助簿。
株式会社が必要とする会計帳票には簿記３級では主要簿と補助簿に分かれる。
主要簿は仕訳帳と総勘定元帳。
仕訳帳は日々の仕訳を日別に記録した帳簿。
日次で出力する時が多いが、量が膨大なので本当にチェックしているのか、と思いたくもなる。
総勘定元帳は、仕訳帳から勘定科目ごとに転記した帳簿。
いわゆるT字形勘定に相当する。
総勘定元帳は月次で出力する時が多い。
総勘定元帳は、国税局や経営者へ提出する会計帳票の元ネタとなる帳簿であり、とても重要。
補助簿は、買掛金元帳、売掛金元帳、商品有高帳は既に上げたが、他に重要な帳簿として、現金出納帳や当座預金出納帳がある。
現金出納帳は、現金の収入と支出を記録した帳簿。小遣い帳と同じ。
当座預金出納帳は、当座預金の取引を記録した帳簿。預金通帳と同じ。
これら二つは日次で出力し、会社の小遣い帳や預金通帳として経理担当者がチェックするのが普通だろう。
会社の資産が減っていないかチェックしているのだ。
そして、日々の仕訳は月次締めで集計され、年度末になったら、１年間の会計期間の帳簿として、損益計算書と貸借対照表を出力する。
会計システムは損益計算書と貸借対照表を出すために存在すると言っていい。
年度末は経理担当者にとって一番忙しい時期。
これら二つの会計帳票を株主に公開して、国税局へ税金を納めるからだ。
年度末決算の作業は、決算整理仕訳という特別な仕訳を作る作業期間を設ける。
決算整理仕訳は棚卸表による修正仕訳を指す。
過去１年間の帳簿や会社の資産、在庫がある倉庫を全てチェックして、資産の状態を洗い出さねばならないのだ。
この時に作られる帳簿が、合計残高試算表と精算表。
合計残高試算表は毎月月次に総勘定元帳を元に作られ、各勘定口座の残高と借方・貸方合計を一覧表示した帳簿。
この帳簿を元に、経理担当者は残高や合計金額を毎月チェックする。
合計残高試算表は上半分がBS、下半分がPLになるように作られているので、すぐに貸借対照表や損益計算書のイメージが湧く。
精算表は、試算表、決算整理仕訳の修正仕訳、、貸借対照表と損益計算書の４個が合わさった一覧表。
精算表からすぐに貸借対照表や損益計算書が作られるので、会計帳票のチェックに使う時が多い重要な帳簿。
これらの帳簿は普通はバッチ処理で日次、月次、年次で作られる。
取引量が多いほど集計処理は大変になるから、DBモデリングやアーキテクチャの腕や品質が問われる。
【6】業務の裏に法律あり。
最近は、J-SOX、個人情報保護法、コンプライアンス、CSRなど会社を縛る色んな法律や概念がある。
業務システムの仕様が複雑になるのは、それらの法律を反映させる必要があるからだ。
今の時代は、会社の管理コストがとても大きくなっていると思う。
簡単にベンチャー企業が作れる時代ではない気がする。
業務システム、会計システムというITインフラがなければ、コンプライアンス上、会社経営はとても危険だろうと思う。
」を読んで気付いたことをメモ。
」をiTunesでダウンロードして、
で読んでみた。
にあるベンダブランチという構成管理技術を使えば、問題を改善できるだろうと思う。
さんのセーフウェア、岸田さんのソフトウェア開発における美学原理の講演を聞いてきた。
」は、600頁にものぼるが、付録の事例が200頁近くもあり、
」「
」など各種の優れた著作・翻訳があるので読んでおいて損はないと思う。
」において「ラストマイル問題」として既にあげられている。
」で詳しく説明されているオープンソースではよく知られた構成管理技術。
最近のコメント