入金管理の表定義を教えて下さい

過去の桐井戸端ＢＢＳ　（桐ver.８）

4418	入金管理の表定義を教えて下さい	野良犬	2000/02/03-15:37
現在、桐８で事務処理を行っていますが、入金管理の表をどのように定義して良いか解らず困っています。　例えば、会員制のスポーツクラブがあって、会員から入会金、年会費を徴収します。また、各会員は、いろいろなコースを申し込むことで実際に利用することができます。（例えば、ゴルフ、ダイビング等）そして、申し込み時に、必要な機材も併せて申し込みます。　目的は、・入会金、会費、各コースの費用、機材等の費用を、合計し、請求書を発行。・実際に振り込まれた日付と金額を入力(分割払いあり）・各会員ごとに、請求金額の内訳と、入金済の日付と金額の一覧表の印刷・入会金、会費、等　勘定科目毎に売り上げの集計のようなことです。実際の一括処理は後で考えるとして、とりあえずどのような表を作ればいいのかアドバイスお願いします。現在、　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へのコメント野良犬さんデータベース設計の参考までにとりあえず、現在の伝票処理や帳簿処理の上で、どの様な入力項目があるかを洗い出してみるのも１つの方法ですね。その中で関連する項目をグルーピングして行きます。もう少し具体的に言えば、大きな模造紙を壁に貼って、丸(○)をいくつか書きます。そして、あちこちの伝票や帳簿の中にあるデータ項目を洗い出して、この丸の中にグループ分けして書き込んで行きます。丸１つが単位となるデータの集りです。例えば会員の個人情報に関するデータの集り、コースに関するデータの集り、という様に分類します。ポストイットの様なものを使って、貼り替えができる様にして分類して行っても良いでしょう。そして、この様にして分類した１つの丸が、１つの表になります。実際には、この様にして洗い出した項目がそのまま表になるとは限りません。・追加すべき項目主キーとなるIDの項目や、外部キーとなる他の表のID項目、ふりがななどの項目各種の判定をするためのフラグの項目、計算式で値を求める項目など・不用な項目手作業では必要になっても電算処理する際には不用な項目。例えば押印の欄そして、これらの丸ができ上がった所で、関連する項目を結びあわせます。例えば会員台帳の会員番号と請求書の会員番号が関連するといった形です。これが結合関係と参照整合性の基礎データになります。とりあえず分かる限りで決めて運用して行くのも１つの方法でしょう。システム分析をきちんと行ってないと、運用の課程で表設計の見直しが必要になるのが普通です。もし御自身で入力作業をしているのであれば、運用しながらしステムを手直しして行くのも１つの方法かと思います。なお、表設計が確定しないと、フォームもレポートもイベントや一括処理も作れないと思います。ですから、仮の形で運用している間は、会話処理で様々な処理を行い、どの様な処理を自動化するのが良いかを、考えて行くのが良いかと思います。佐田守弘(KS-00119)

戻る