プロが教える店舗&オフィスのセキュリティ対策術

アクセスで悪戦苦闘しています。
どなたかお力を貸してくださいませ

下記の内容を入力するフォームを作成しています
(後に決められた形式で出力します)

工事番号
部門
工事名
契約日
発注者
住所
電話
FAX
メール
担当者
弊社担当者
請求書番号
請求日
請求金額
請求書番号2
請求日2
請求金額2
請求書番号3
請求日3
請求金額3
請求書番号4
請求日4
請求金額4
請求書番号5
請求日5
請求金額5
請求合計(1~5の合計額)
回収日
回収額
回収額合計
回収日2
回収額2
回収額合計2
回収日3
回収額3
回収額合計3
回収日4
回収額4
回収額合計4
回収日5
回収額5
回収額合計5
注文書 有・無
完了(済・未)

...他省略

上記の内容で下記のようにテーブルを作成しました

◎工事マスタ
工事番号(主キー)/部門コード/工事名/契約日/注文書 有・無/**発注者/**住所/**電話/**FAX/**メール/**担当者/社員コード…以下略

◎部門マスタ
部門コード(主キー)/部門名

◎社員マスタ
社員コード(主キー)/弊社担当者

◎請求マスタ
請求ID(主キー)/請負額/税/合計/請求書番号/請求日/請求金額
請求書番号2/請求日2/請求金額2/請求書番号3/請求日3/請求金額3/請求書番号4/請求日4/請求金額4/請求書番号5/請求日5/請求金額5/請求合計(1~5の合計額)/回収日/回収額/回収額合計/回収日2/回収額2/回収額合計2/回収日3/回収額3/回収額合計3/回収日4/回収額4/回収額合計4/回収日5/回収額5/回収額合計5
完了(済・未)

リレーションシップ
工事コード...工事マスタ(1)請求マスタ(∞)
社員コード...社員マスタ(1)工事マスタ(∞)
部門コード...部門マスタ(1)工事マスタ(∞)

に設定しました

ウィザードを使って請求マスタの全項目を入れた単票フォーム(サブA)を作成
ウィザードを使って工事マスタの全項目が入った(クエリA)を作成し
それをもとに、ウィザードを使って(フォームA)を作成し、サブフォームに(サブA(単票))を設定しました。

一応どうにか形にはなりましたが

本当は工事マスタ内の**がついているフィールドは
顧客マスタとして分けていたのですが
フォームでうまく入力ができなかったので
とりえず、工事マスタにくっつけています。

何度も同じ電話や住所を打つのは面倒ですし、
テーブルを一つにしたこと自体抵抗があります。
しかし、同じ発注者でも、工事によって担当者が変わるので
こういう場合はどう対応するべきなのかわかりません。

また、顧客マスタを別につくり、
コンボボックスにして
反映させるという方法も試してみましたが
新規に入力する場合は、上記のフォームにそのまま
入力したいと思っています。

上記の内容で
どのような設定をすればよいのでしょうか?

ウィザードでで顧客マスタと工事マスタを選択したクエリを作成して試してみたのですが
それだと、フォームを開いたときに、工事マスタの既存のレコードが表示されなかったり、入力エラーが出たりとどうもうまくいきません。

もうひとつの問題は請求日と回収日なのですが
それは別途質問させていただきたいと思います。

説明下手ですが どなたかお力を貸してくださいますようお願いいたします

A 回答 (2件)

>新規に入力する場合は、上記のフォームにそのまま入力したいと思っています。



考え直されたがいいです。

・請求書台帳には、顧客台帳を表示するだけが簡単です。
・どうせ、顧客台帳登録フォームがないと不便です。
・列[顧客台帳_ID]で0を入力されたら顧客台帳登録フォームをオープンし登録。
・顧客台帳登録フォームを閉じると列[顧客台帳_ID]に新規登録が反映されている。
・請求書台帳の顧客台帳の詳細データの表示も更新されている。

この方が簡単だと思いますよ。
    • good
    • 0

まあ、後々のことを考えれば<ありきたりな設計>に戻すべきでしょう。


なお、判りやすくするために主キーは全て[ID]にしています。
なお、判りやすくするために連結している列名は、[テーブル名+ID]にしています。

*************************
 顧客台帳
*************************

[ID]_[顧客名_____]_[読み________________]_[郵便番号]_[住所____________]_[電話___________]_[FAX____________]
___1__木下 健二____きのした けんじ_____1112222___東京都1-11___03-111-1111__03-111-1119
___2__山田 太郎____やまだ たろう________1113333___東京都1-12___03-111-2222__03-111-2229

1、[顧客台帳]に列[読み]がないと、少し、検索が面倒になります。
2、[顧客台帳]に列[郵便番号]がばいと、住所の入力が面倒かと思います。

*************************
 顧客側担当者名簿
*************************

[ID]_[顧客台帳_ID]_[表示順]_[担当者名___]
__1___木下 健二_______________1___毛利 素直
__2___木下 健二_______________2____柴田 幸一
__3___山田 太郎_______________1____小島 一
__4___山田 太郎_______________2____山中 清

[顧客台帳_ID]=SELECT 顧客台帳.[ID], 顧客台帳.顧客名, * FROM 顧客台帳;

複数の顧客側の担当者は、このような[顧客側担当者名簿]で管理します。

3、列[表示順]を設けて主担当がトップに表示されるようにすると便利です。
  これで、[表示順]=1は<既定の担当者>扱いできます。

*************************
 社員名簿
*************************

[ID]_[弊社担当者]
___1___001:鈴木 一郎
___2___002:中村 主水

4、[社員名簿]の[弊社担当者]のデータに[社員コード]を付けて並びを制御すると共に選択を容易にする手もあります。

*************************
 部門一覧
*************************

[ID]_[部門名]
__1___部門A
__2___部門B

*************************
 請求書元帳
*************************

[工事番号]_[部門一覧_ID]_[工事名____________________]_[契約日_______]_[顧客台帳_ID]_[顧客側担当者名簿_ID]_[社員名簿_ID]
200812001__部門A__________東京湾護岸工事____________2008/12/01___木下 健二______毛利 素直_________________001:鈴木 一郎
200812002__部門A__________東京湾護岸工事追加分___2008/12/01___木下 健二______柴田 幸一_________________001:鈴木 一郎

5、[工事履歴]には[顧客台帳_ID]と[顧客側担当者名簿_ID]とを設けます。
  これで、[顧客台帳_ID]が決まればコンボボックス[顧客側担当者名簿_ID]のアイテムも絞り込まれます。

[部門一覧_ID]=SELECT 部門一覧.ID, 部門一覧.部門名, * FROM 部門一覧;
[顧客台帳_ID]=SELECT 顧客台帳.ID, 顧客台帳.顧客名, * FROM 顧客台帳;
[顧客側担当者名簿_ID]=SELECT 顧客側担当者名簿.ID, 顧客側担当者名簿.担当者名, * FROM 顧客側担当者名簿;
[社員名簿_ID]=SELECT 社員名簿.ID, 社員名簿.弊社担当者, * FROM 社員名簿;

*************************
 請求書明細
*************************

[請求書元帳_ID]_[行番号]_[請求書番号]_[適用税率]_[税抜請求金額]_[消費税額]_[合計請求金額]
___200812001_____________1___200812001________5.00%_____________\1,000__________\50___________\1,050
___200812001_____________2___200812002________5.00%_____________\1,000__________\50___________\1,050
___200812002_____________1___200812003________5.00%_____________\2,000_________\100___________\2,100

6、一番やっかいなのは、[請求書台帳]の[行番号]の管理です。
  なぜなら、同じ請求書で3行の請求明細があって2行目が削除されることもあるからです。
  その後、そのミスに気付いて2行目を追加もありえます。
  ですから、かかる[行番号]は必要です。
  しかし、この管理は少しややこしいです。

ともかく、テーブル設計が全てです。
ここで妥協しないで当初設計に立ち戻られることをお勧めします。
幾つかのコンボボックスのソースも合わせて示しています。
このようにテーブルの構造はデータを参照する上で非常に大事ですよ。
    • good
    • 0
この回答へのお礼

すいません、
だいぶ前に一度検証してみます!と
お礼をしたつもりなのですが
反映されてませんでした 
年末年始を挟んでしまってたので
検証作業が遅れてしまい
お返事遅くなってしまって大変申しわけありません
上記のようなテーブル構成に変えてみました!
いくつか課題はあるものの
理想的に動かせることができてとても感謝しています。
初心者の私に、とても丁寧にわかりやすいアドバイスをしていただき
本当に言葉にならないほど感謝しています。
ありがとうございました。
まだまだわからないことだらけなので
また何かありましたら どうぞよろしくお願いいたします
本当にありがとうございました!!!!!!!!!

お礼日時:2009/01/09 11:23

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!