- ベストアンサー
Access2007での商品修理受付状態管理について
- Access2007を使用して、商品の修理受付状態を管理するデーターベースを作成している初心者です。商品ごとに異なる管理番号を取得し、重複登録のない設定もしたいです。
- 現在、作成したテーブルとフォームは機能していません。修理受付入力と修理受付明細、作業完了入力、作業完了明細のフォームを作成予定です。
- 修理受付明細フォームでの明細行番号の表示方法、現在の状態と修理回数の自動表示方法がわかりません。ご教授いただければ幸いです。
- helpaccess
- お礼率5% (2/37)
- その他(データベース)
- 回答数37
- ありがとう数7
- みんなの回答 （37）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
＃１～＃４です サンプルＤＢを試作してみましたが、結構面倒で、それ以上に説明は大変そうです。と云うことで取り敢えず簡単なことから。 >1つのフォームに、1つのテーブルが必要と思っておりました。 一般的にはフォームにテーブルをそのまま対応させることはありません。クエリーを介在させます。例えば一覧表示するとき、アイウエオ順や年月日順に表示しようとすればクエリー介在が必要です。またテーブルはレコードの並び順を保証しませんから、いつ利用しにくい並びになるか判らないからです >受付フォームにて、受付をし、作業が完了した際には、再度、受付フォームを開いて、完了日を入力すれば良いのですよね？！ これでも良いですが、クエリーを使用すれば、完了日未記入のものだけを一覧表示して処理するようなこともできます。どちらかというとその方が良いでしょう >顧客名さえあれば電話番号や住所等はこのシステムでは必要ないので、顧客ID（オートナンバー）顧客名、ふりがな、備考のみで良いことになります。 他のＤＢに顧客名関連の情報がある場合は、それとリンクして使用します。ですから当該ＤＢでは顧客参照ＩＤだけで済ませます。リレーショナルＤＢでは同じデータの複数登録はできる限り避けるべきです。入力手間が増える弊害もさることながら、入力回数が増えれば、誤りの発生もほぼそれに正比例するためです >コンボボックスで選択 コンボボックスの選択も便利ですが、選択対象がせいぜい１０くらいまで、無理しても２０以下にしたいです。それ以上では選択が大変です。その場合は一覧表示し、そこから選択して処理の流れになります。さらにレコード数が多いときはグループ分け、さらには「大分類」「中分類」「小分類」のような仕掛けも必要になります。 以上もふまえサンプルＤＢの仕様ですが １．商品一覧表示フォームから当該商品を選択し、この商品の管理番号一覧フォームを開く ２．管理番号一覧フォームで目的とする管理番号を選択し、修理履歴フォームを開く ３．管理番号一覧フォームは新しい管理番号を追加でき、これはそれまでの最大プラス１になる ４．修理履歴テーブルは管理番号ごとに連番をもつ ５．修理履歴フォームから個々の修理明細フォームを開ける ６．修理明細フォームは上記の流れ以外、現在対象絞り込み（完了日未記入だけを絞り込む）からも開けるようにする ざっとこんな感じでしょうか？よろしいか、あるいは仕様変更を補足してください。
その他の回答 (36)
＃６で示した大分類選択方法は、一覧ができないので使いにくいです。しかしAccess2000では、「親子フォームの親は単票形式」と云う、仕様上の制限があり、何ともなりません。Access2007は持っていないので試験できませんが、お試しになり「帳票フォーム」が可能であれば変更してください。もしできなければその旨を補足してください。コンボボックスとＶＢＡを使用する改善案を、後で示します で、以下は中分類から商品選択です １．商品一覧フォーム作成 「中分類一覧フォーム」と同様に作ってください ２．中分類選択フォーム作成 これも「大分類選択フォーム」と同様に作り、商品一覧フォームを子フォームとします ３．移動ボタンなどの非表示 中分類を替えることにより、商品が絞り込まれることを確認したらフォームの書式で「レコードセレクタ」と「移動ボタン」を「いいえ」に替え、非表示にしてください。 ４．中分類一覧フォーム変更 中分類一覧フォームの「中分類名称」テキストボックスの右側に、コマンドボタンを追加します（ツールボックスから持ってくる）。ウィザードが起動するので フォームの操作/フォームを開く/中分類選択フォーム/特定のレコードを表示する と進み 中分類ID<->中分類ID と関連づけてください。ボタンの表示は「文字列」ラジオボタンをチェックして「商品選択」ぐらいでよいでしょう（適当に変更してください）。 これを動かして、一覧から選んだ中分類で、商品が絞り込まれることを確認してください。これが上手く行けば、大分類選択から商品選択までが実行できるはずです
補足
こんばんは。 早速、試してみました！ >＃６で示した大分類選択方法は、一覧ができないので使いにくいです。しかしAccess2000では、「親子フォームの親は単票形式」と云う、仕様上の制限があり、何ともなりません。Access2007は持っていないので試験できませんが、お試しになり「帳票フォーム」が可能であれば変更してください。 についてですが、Access2007でも、親フォームは単票フォームしか使えないようです。恐れ入りますが、改善案をご教授くださいませ。 次に、１～３まではうまく動いたのですが、４でつまずいています。 中分類一覧フォームにて、「商品選択」ボタンをクリックすると、どの中分類のボタンをクリックしても、中分類ID:１ 中分類名称：Aaしか表示されません。サブフォームの商品一覧フォームは、中分類IDで絞り込まれた商品のAa1、Aa2、Aa3（私がテストで入力したものです。）が表示されています。 （たとえば、中分類一覧フォームにて、中分類ID:４ 中分類名称：Baの横の「商品選択」ボタンをクリックしても、中分類ID:１ 中分類名称：Aa、サブフォームの商品一覧フォームは、Aa1、Aa2、Aa3となります。） どこか、私の操作が誤っておりますでしょうか。恐れ入りますが、検証くださいませ。 また、質問なのですが、大分類や中分類の選択フォームにて、選択のテストをする際、名称欄の内容を手打ちで入力し直した場合には、テーブルのレコード内容が書き換えられてしまうのですが、手打ちで入力してテストすることは間違ってるのでしょうか。実際に使用する段階にきた際には、手打ちで入力するものではないのでしょうか。 恐らく、初歩的なことだとは思うのですが、どうか教えてくださいますようお願い申し上げます。ほんとうにド素人ですみません。 どうか、よろしくお願いいたします。
「大分類」「中分類」を利用して商品選択を行う一案。今回「小分類」は省略しました。基本的には同じ事の繰り返しですが、アクセスの仕様により面倒です。それからテーブルやフォームの名称は、説明しやすいように適当なものを使用しています。貴方での環境に合わせ、適切なものに変えてください。いい加減な名称が着いていると、システムが大きくなったり、担当者が交替した場合に、訳がわからなくなります。では １．テーブルの追加作成 「大分類テーブル」 大分類ID：オートナンバー 大分類名称：テキスト型 「中分類テーブル」 中分類ID：オートナンバー 中分類名称：テキスト型 大分類ID：数値型 ２．フィールドの追加 「商品テーブル」 中分類ID:数値型 ３．フォームの作成 「中分類一覧フォーム」 新規/デザインビュー で開始する。プロパティウィンドウのレコードソース（空欄）の右側に出る「...」ボタンをクリックし、クエリビルダを起動する。 テーブル「中分類テーブル」を「追加」し、全ての項目をフィールドに割り振る。中分類名称で「昇順」になるようにセット プロパティの更新をして、レコードソース欄から移動すると。フィールドリストが表示される。「中分類名称」と「中分類ID」を貼り付け、フォームの「規定のビュー」は「帳票にする」これをほぞんして「中分類一覧フォーム」作成終了 「大分類選択フォーム」 レコードソースは「大分類テーブル」、項目は「大分類ID」と「大分類名称」（昇順に並べ替え。フォームの「規定のビュー」は「単票」 ツールボックスの中から「サブフォーム/サブレポート」ボタンを押し、フォーム上に貼り付ける。ウィザードが起動するので ・既存のフォームを利用するラジオボタンチェック ・「中分類一覧フォーム」を選択し「次へ」ボタン ・一覧から選択するするラジオボタンチェックで、「大分類IDでリンクし、<SQLステートメント>の各レコうー土に<ＳＱＬが反転していることを確認し「次へ」ボタン、「完了」ボタン ・フォームを動かして、大分類選択を変えたとき、その下にある中分類が表示されることを確認する。ちなみに試験データは 大分類 ID 名称 1 A 2 B 3 C 中分類 ID 名称 大分類ID 1 Aa 1 2 Ab 1 3 Ac 1 4 Ba 2 5 Bb 2 6 Bc 2 7 Ca 3 8 Cb 3 9 Cc 3 など作っておくと試験が楽。取り敢えずこれを動かしてください。 先は長い(^^;
補足
「大分類」「中分類」について、できました！！ とってもわかりやすいご説明に心より感謝いたします。 試験で動かしてみたところ、大分類の名称を変更すると、サブフォームの中分類が変わりました！！
＃１、＃２、＃３です。サンプルを多少いじって「管理番号」の意味が推測できました。商品と顧客の関係を管理するためですね。ということで「このようなテーブルは不必要にも思えます。」は誤り。
補足
ほんとうに、ほんとうに感謝いたします。 ＃１、＃２、＃３についてですが、 まず、＃１、＃３について。 根本的に希望のシステムは、商品1点、1点を管理番号で管理することを目的としています。 売り上げなどについては、すでに他のシステムで管理をしており、今回作っているものは、あくまでも、「商品1点、1点の修理受付状況ならびに修理履歴を管理番号で管理する」というシステムです。 そのため、どちらかというと、顧客ベースではなく、管理番号ベースで商品1点1点を管理したいのです。 ちなみに、管理番号については、商品の修理作業をする際に商品自体に刻印する番号となっておりますので、これだけは必須となります。 >ひょっとしてフォームにはテーブルがそれぞれ対応すると誤解されているのでしょうか？ については、完全に誤解しているかもしれません。 1つのフォームに、1つのテーブルが必要と思っておりました。 また、確かに、受付のフォームに、作業完了日と、引渡し日の項目があれば、作業完了フォームは不要ですよね？！ 受付フォームにて、受付をし、作業が完了した際には、再度、受付フォームを開いて、完了日を入力すれば良いのですよね？！ ＃２についてです。 各テーブルに主キーは必須と思っており、無意味にすべてに設定していたようです。 商品テーブルについては、商品名（商品名が型番のようなものです。）さえ登録できれば良いので、 「商品テーブル」は、商品ID（オートナンバー）、商品名、備考（備考は本当に一応設定しておこうと思います。）のみで良いということになります。 とにかく、実際に入力作業をすることになった際には、現場の作業員が入力するため、なるべく簡潔で、間違い入力をしないようにと考えております。 そのため、顧客名や商品名も手打ちで入力しても良いのですが、あらかじめそれぞれのテーブルに入力しておいて、コンボボックスで選択できるようにしたいと思っております。 顧客テーブルについても、顧客名さえあれば電話番号や住所等はこのシステムでは必要ないので、顧客ID（オートナンバー）顧客名、ふりがな、備考のみで良いことになります。 すみません、本当にあつかましく、いろいろ考えてくださり、感謝感謝であります。 どうか、良い方法をご教授くださいませ。
＃１、＃２です。書き忘れた点をいくつか >「商品テーブル」商品ID（主キー）、商品名、顧客参照ID、備考 普通は「顧客参照ID」を入れずに、「仕入れ先ID」とか「単価」などから構成すると考えます。 商品IDに限らずIDを（主キー）にしていますが、意味がないと考えます。IDはオートナンバーにすれば重複は起きません。これをリレーションに使うのはよいと思います。でも主キーは顧客テーブルで云えば「顧客名」と「電話番号」あるいは「住所」などにして、二重登録を防ぐのに利用するべきです。
＃１です。少し真面目に回答しようかと、サンプルデータベースを作り始めて、判らないところや疑問に感ずるところが出てきました。まず 「管理番号テーブル」はなんのためにあるのでしょうか。商品と顧客の関係を一元的に管理し、修理の履歴などを見るためでしょうか。同じ商品を、同じ顧客が、複数持つのでなければ、このようなテーブルは不必要にも思えます。 「修理関係のテーブル」 普通は一つのテーブルで ・受付日 ・作業開始日 ・作業完了日 ・引き渡し日 ・入力者ID ・顧客ID ・商品ID ・その他諸々 などで管理できると考えます。修理履歴も「商品ID」と「顧客ID」ですぐまとまるし、「作業開始日」で時系列化や修理回数もすぐ出ます。 >（修理受付をすると、内容が作業完了にコピーされるようにするつもりです。） このような作業も不要では？ ひょっとしてフォームにはテーブルがそれぞれ対応すると誤解されているのでしょうか？
>商品AAAの管理番号001という商品は、1つしか存在しません。管理番号テーブルにて、重複登録をしない設定をしたい 複数のフィールドにまたがって主キーを作成できます。なので「商品参照ID」と「管理番号」を主キーにすれば重複できなくなります。「管理番号ID」はオートナンバーにして、リレーションなどにはこれを利用すればよいでしょう。 >明細行番号の表示の仕方 サブクエリーを使用する方法しか思いつきませんが、多少面倒です。 >修理受付明細フォームでの、現在の状態、修理回数の自動表示の方法 何を希望されているのか具体的イメージが湧きません(^^;
補足
ご回答いただき、ほんとうに感謝いたします。 早速、主キーについては訂正をいたしました。ほんとうにありがとうございました。 また、明細行番号につきましては、一度にまとめて20件の入力をした際などに、入力漏れがないか確認できやすくなると思い、行数が表示できればなと思っておりました。 なお、 >修理受付明細フォームでの、現在の状態、修理回数の自動表示の方法 についてですが、実際に入力を始めた際、絶対に間違い入力があってはならないものなので、入力状況を随時確認しながらできればと思い、入力時に、その商品が前回の修理の際に確実に作業完了入力がなされているかが簡単に確認できるようにしたいと思っております。 もし、受付する際の状態が「受付中」になっていたら、作業完了入力ができていないことがわかりますし、手打ちで管理番号を入力した際の入力ミスを防げると考えております。 また、修理回数についても、商品により、修理の限界数があるため、受付入力の際に、それも簡単に表示でき、確認できれば最高のシステムになると思っております。 何か、良い方法はございますでしょうか。
補足
貴重なお時間をたくさん、たくさんさいていただき、また、いろいろとお考えいただき、ほんとうにほんとうに心より感謝申し上げます。 早速ですが、 >>受付フォームにて、受付をし、作業が完了した際には、再度、受付フォームを開いて、完了日を入力すれば良いのですよね？！ >これでも良いですが、クエリーを使用すれば、完了日未記入のものだけを一覧表示して処理するようなこともできます。どちらかというとその方が良いでしょう につきましては、fuuten_no_nekoさまがおっしゃられるように、完了日未記入のものだけを一覧表示して処理する方法が私にもできるようであれば、是非そうしたいです！！ 次に、顧客名についてですが、私の書き方が悪かったのですが、他のDBに存在するというのは、Accessではなく、全く異なったソフトにて売り上げ管理は行っておりますので、とりあえず、今回、顧客ID（オートナンバー）顧客名、ふりがな、備考のテーブルは必要になるかと思います。合ってますでしょうか？ >>コンボボックスで選択 につきましては、ご指摘のように、商品の種類はコンボボックスで表示できる限界の10～20以上を裕に越し、現時点で数百ありますので、ご提案のグループ分け、さらには「大分類」「中分類」「小分類」の方法を取りたいと思います。 DBの仕様についてですが、 私にできるようであれば、ご提案の１～６の内容は最高！！です。 ただ、 >３．管理番号一覧フォームは新しい管理番号を追加でき、これはそれまでの最大プラス１になる の「最大プラス１になる」についてですが、 現在、すでに管理番号を取得している商品があり、それは、初めて受付をした日プラス2桁の連番を取っております。 例えば、商品Aを2009年3月11日に3点新規受付したとすると、管理番号は 商品A 09031101 商品A 09031102 商品A 09031103 となり、同じ、2009年3月11日に商品Bを3本新規受付すれば、 商品B 09031101 商品B 09031102 商品B 09031103 となっております。また、現場の人間に確認をしたところ、管理番号の取得形式は上記のとおりしたいとのことですので、なんとか、このような取得方法はできますでしょうか。 ほんとうに厚かましく申し訳ないのですが、どうかよろしくお願い申し上げます。