過去の桐井戸端BBS (桐ver.8)
4418 入金管理の表定義を教えて下さい 野良犬 2000/02/03-15:37
現在、桐8で事務処理を行っていますが、入金管理の表をどのように
定義して良いか解らず困っています。

 例えば、会員制のスポーツクラブがあって、会員から入会金、年会費を
徴収します。また、各会員は、いろいろなコースを申し込むことで実際に
利用することができます。(例えば、ゴルフ、ダイビング等)そして、
申し込み時に、必要な機材も併せて申し込みます。
 目的は、
・入会金、会費、各コースの費用、機材等の費用を、合計し、請求書を発行。
・実際に振り込まれた日付と金額を入力(分割払いあり)
・各会員ごとに、請求金額の内訳と、入金済の日付と金額の一覧表の印刷
・入会金、会費、等 勘定科目毎に売り上げの集計

のようなことです。実際の一括処理は後で考えるとして、とりあえずどのよ
うな表を作ればいいのかアドバイスお願いします。

現在、
 KAIIN.TBL 会員情報、一意の会員番号を各会員に割り当て済
 TOUROKU.TBL 各会員がどのコースを申し込んだか。
 COURSE.TBL 各コース毎の情報
のような表があります。

宜しくお願いします。
4425 Re:入金管理の表定義を教えて下さい 宮城 2000/02/03-21:02
記事番号4418へのコメント
すごいことを質問なさいますね。ちょっと、びびります。

現状、手書き伝票とつけ込み帳簿はおありなのではないでしょうか。それを
置き換えていくつもりで設計なさるのがいいのでは。

細切れイメージでやりますと、会員ナンバー、請求ナンバーをキーにした
「請求テーブル」でも作るんでしょう。当然会員ナンバーも取り込んでおく。
費用の性格をしめすもの、金額、請求年月日、納期、入金年月日、入金完了
年月日、支払完了マーク、その他必要なフラグを持たせますか。

これに対して、「入金テーブル」は、会員ナンバー、請求ナンバー、(分納
ナンバー?)、あたりをキーにする。金額、入金年月日、分納マークぐらい?

費用の性格をしめすものはマスターにしておくんでしょうか。

消費税計算は工夫がいりますね。

びびるというのは、これ、システム設計そのものですよ。

>一括処理は後で考えるとして

現実のプログラミングはそんなものではありません。「フラグ」って書いて
ますが、ロジックを成立させるためにだけ必要になる項目も発生します。練
って、練って、表設計したつもりなのに逆戻りになることも珍しくないです。

どんなに一般的な機能でも、使う人が「いらない」といったらお終い。使う
人が考えない限り、システムにもとめる機能は誰も考えてくれません。

>(分割払いあり)

とさりげなくお書きになっていますが、こんなことですら、意地悪く言えば
「だからどうしてほしいんですか?」となってしまいます。

4430 Re:入金管理の表定義を教えて下さい 佐田 守弘 2000/02/03-23:30
記事番号4418へのコメント
野良犬さん

ちょっと脱線した話になりますが、
*「大学に行くにはどうしたら良いですか」
という質問があったとします。もし「大学までの道順を教えて」であれば、簡単に
教えられますが、「大学に入学する方法を教えて」だと、簡単ではありません。

宮城さんも書かれている通り、御質問の主旨は、システム設計の課題ではないで
しょうか。システム設計は、システム構築の前の大切なワークで、ここに充分な
時間を掛けるかどうかで、システムのでき映えが変わって来るほど重要です。建
築物にたとえれば、基礎工事の様なものです。

●システム分析
実は、システム設計の前にシステム分析も必要です。これは以外とおろそかにさ
れがちです。システム分析では業務の洗い出しと、その関連性をマッピングして
行きます。
業務の洗い出しでは、業務の無駄がないか、改善すべき点はないかを明らかにし
、時として「この組織は無駄なのではないか。あの役職者は必要なのか?」にま
で言及します。
これは、建築にたとえれば、基礎工事の前に地中の障害物を撤去したり、地質調
査をする様なものです。これを行わないと基礎工事に相当するシステム設計もで
きません。

●システム設計
システム分析で作り上げたマップ(システム連関図)を元にして、どの部分につい
てのシステムを構築するかの絞り込みを行います。もちろん、全ての業務のシス
テム化もできないわけではありませんが、お金と費用がかかりすぎますから、一
般的には重点化します。
ちなみに「全部」といった答はなしです。何も考えないでの「全部」とは、後か
らの追加変更でシステム設計のやり直しの繰り返しになり、結局は何もしない事
と同じになります。

おそらく、今回の御質問では「入金処理の部分」というのがそのポイントなので
しょう。

●表の設計
システム設計の結果に基づいて、どの様な項目からなるどの様な表を作る必要が
あるかを決めて行きます。どの様な表を作ってもそこそこの事はできるのですが
、どの様な項目をどの表に持たせるかと言った、データベースの設計が、その後
のシステム構築のキーポイントになります。

その意味で、このご質問をされたのだと思うのですが、上記の様に、もし私が作
るとしたら、システム分析からシステム設計を行った後で行う設計であり、書か
れた情報だけで表の設計をするのは難しいかと思います。

●安直なアドバイス
宮城さんも書かれている通り、手作業で入力する時の作業を想定しながら必要な
項目を作ってみてはいかがでしょうか。おそらく業務内容を知らない第三者には
、どの様な項目を作るべきかを考えるのが難しいと思います。

佐田守弘(KS-00119)



4439 Re:入金管理の表定義を教えて下さい MIT 2000/02/04-11:18
記事番号4418へのコメント
MITと申します。
システム開発は皆様のご発言通り「こうです」と説明できる
性格のものではありませんね。

私も以前,スポーツクラブの会計システムを組んだことが
あります。
入金管理の状況は千差万別と思いますのが参考までに
「会員管理は有効期限をベースとする」
の考え方でシステム全体がスッキリまとまった経験
があります。

以上,本当にご参考までMIT

4440 Re:入金管理の表定義を教えて下さい 宮城 2000/02/04-12:14
記事番号4425へのコメント
自分で考えなきゃだめとはいうものの、途方にくれたような心境になるのは
わからなくもないです。ある程度経験を積むか、経験者のマンツーマン指導
でも受けない限り、白紙の状態から表を定義しようとするのは無謀というべ
きかも。

誰でもそうだと思いますが、「模倣」から入るものでしょう。そのまま使っ
てみる、項目を追加したり削除してみる、定義を少し変えてみる。そうやっ
て覚えていくものだと思います。

適当なサンプルではないかもしれませんが、桐添付のサンプルの次あたりを
お薦めしときます。とりあえず TBLだけご参照下さい。

K3\KIRIV8\SAMPLE\印刷伝票\現金出納(以下のTBL)
K3\KIRIV8\SAMPLE\印刷伝票\販売伝票(以下のTBL)

4441 Re:入金管理の表定義を教えて下さい 宮城 2000/02/04-12:33
記事番号4440へのコメント
ほかならない佐田さんのサイトのほうがもっとよろしいか。

http://www.ne.jp/asahi/m.sada/kiri/GUIDE/GUIDE_TOP.html
4465 Re:入金管理の表定義を教えて下さい 野良犬 2000/02/05-02:19
記事番号4440へのコメント
宮城さんは No.4440「Re:入金管理の表定義を教えて下さい」で書きました。

>誰でもそうだと思いますが、「模倣」から入るものでしょう。そのまま使っ
>てみる、項目を追加したり削除してみる、定義を少し変えてみる。そうやっ
>て覚えていくものだと思います。

アドバイスありがとうございます。なるだけたくさんサンプルを集めて
真似るところからやっていこうとおもいます。



4469 Re:入金管理の表定義を教えて下さい 佐田 守弘 2000/02/05-10:47
記事番号4465へのコメント
野良犬さん

データベース設計の参考までに
とりあえず、現在の伝票処理や帳簿処理の上で、どの様な入力項目があるかを洗い
出してみるのも1つの方法ですね。その中で関連する項目をグルーピングして行き
ます。
もう少し具体的に言えば、大きな模造紙を壁に貼って、丸(○)をいくつか書きます
。そして、あちこちの伝票や帳簿の中にあるデータ項目を洗い出して、この丸の中
にグループ分けして書き込んで行きます。
丸1つが単位となるデータの集りです。例えば会員の個人情報に関するデータの集
り、コースに関するデータの集り、という様に分類します。
ポストイットの様なものを使って、貼り替えができる様にして分類して行っても良
いでしょう。
そして、この様にして分類した1つの丸が、1つの表になります。

実際には、この様にして洗い出した項目がそのまま表になるとは限りません。
・追加すべき項目
主キーとなるIDの項目や、外部キーとなる他の表のID項目、ふりがななどの項目
各種の判定をするためのフラグの項目、計算式で値を求める項目など
・不用な項目
手作業では必要になっても電算処理する際には不用な項目。例えば押印の欄

そして、これらの丸ができ上がった所で、関連する項目を結びあわせます。例えば
会員台帳の会員番号と請求書の会員番号が関連するといった形です。これが結合関
係と参照整合性の基礎データになります。

とりあえず分かる限りで決めて運用して行くのも1つの方法でしょう。システム分
析をきちんと行ってないと、運用の課程で表設計の見直しが必要になるのが普通で
す。
もし御自身で入力作業をしているのであれば、運用しながらしステムを手直しして
行くのも1つの方法かと思います。

なお、表設計が確定しないと、フォームもレポートもイベントや一括処理も作れな
いと思います。ですから、仮の形で運用している間は、会話処理で様々な処理を行
い、どの様な処理を自動化するのが良いかを、考えて行くのが良いかと思います。

佐田守弘(KS-00119)

戻る