受注明細テーブルについて

Access2013 vba

今工事関係のシステムを作っています。

・工事受注の情報を入力する画面A
・工事部材の注文明細を入力する画面B（帳票・サブフォーム）
・工事の管理情報を入力する画面C（単票・メインフォーム）
・工事の発注明細を入力する画面C2（帳票・サブフォーム）
・受注明細画面D（帳票フォーム）

とあるとして

【A】受注情報管理
・受注ID(main key)
・受注日
・依頼内容
・部材注文合計金額
・発注合計金額

【B】部材注文明細
・部材明細ID2 (main key)
・受注ID(foreign key)
・品番
・商品名
・単価
・数
・摘要
【C】工事管理情報→依頼先会社毎に、受注IDに紐づく
・工事管理ID (main key)
・受注ID (foreign key)
・依頼先会社ID(foreign key)
・工事開始日
・工事終了日
【C2】工事管理─仮発注明細
・明細ID4(main)
・工事管理ID
・項目名
・単価
・数量
・摘要

受注明細を、部材注文明細と仮発注明細から作成するやり方を考えました。
BとC2のレコードから、受注IDをキーにして、全てのレコードを以下のDの受注明細テーブルに格納する・・・。この時、B, C2と、Dは非同期→すると、もし、部材明細や仮発注明細が変更されると、Dが連動してその変更内容が反映出来ません。このやり方が良いのかとうか、いまいちわかりません。ご助言をお願いします・・・。

【D】受注明細
・受注明細ID5(main)
・受注ID
・項目名
・単価
・数量
・摘要
・請求ID

No.5 ベストアンサー 回答者： f_a_007 回答日時： 2015/01/14 10:41

【アドバイス】質問のテーマに関して再考を！

今回のテーマは、

・受注情報管理とは異なる工事発注伝票の仕様に関わる質疑応答。

さて、[工事発注伝票]は、これまでの受注情報管理の考えだけでは不十分です。

１、発生主義で情報を管理しなければならない。
２．月単位での締切処理に対応しなければならない。

さて、そうなると[工事依頼伝票]と[工事依頼明細]の設計がこれまでと多少違ってきます。それは、[工事依頼明細].[行区分]の登場です。

[行区分]=0: 通常行
[行区分]=1: キャンセル行
[行区分]=9: 調節行

もう一つは、[工事依頼明細].[見積金額]。これは、伝票発行時点での[工事台帳明細].[単価]×[数量]のコピー。ここは、決して、リンクさせてはいけません。あくまでも、発生主義の原則を貫きます。

【工事依頼伝票】

ID
日時
依頼先_ID
摘要

【工事依頼明細】

ID
工事依頼伝票_ID
行番号
行区分
受注台帳_ID
工事台帳_ID
受注案件名
工事名
発注金額
見積金額
摘要

さて、こういう風に質問のテーマに関して考察していけば、[工事依頼明細].[受注台帳_ID]はコンボボックスで選択もありという状況が見えてくるかと思います。また、テーブル[受注台帳]に[工事依頼完了]（Yes/No）列があったら・・・。ということも。

と、

この回答へのお礼

お忙しい中、ご回答していただきありがとうございます。
ご説明していただいた中で、良くわからない言葉があるために、混乱してしまいます。
ですので確認させて欲しいのですが、

*1)工事依頼明細とは、私が質問のなかで書いた工事発注明細のことを指していますか？
*2)行区分の調節行とは、金額の調整、値引きとかそういうことに使うということでしょうか？
*3)見積金額が、単価×数量のコピーとはその計算結果の値自体をセットすることでしょうか？
*4)工事依頼明細の工事台帳IDが、何のことかわからないです。

色々、おききしてしまいすみませんが、宜しくお願いします。

お礼日時：2015/01/14 11:55

No.9 回答者： f_a_007 回答日時： 2015/01/14 20:44

Q、工事依頼元へ出す見積もり書作成の場合、既に入力している部材注文一覧と仮工事発注一覧のレコードの項目名、単価、数量を受注IDで紐付けたもの全部使用したいのです。

その場合、クエリーでそうなるようなものを作成し、それをコンボボックスなどで選択するのも一つの手でしょうか・・・
A、No!

　私の作法では、まず、Accessのクエリーなるものは一切利用しません。

PS、まず、入力フォーム、検索フォームのデッサンを！

　一体、ユーザーが直感的に手早く作業するには？ということを念頭に。その実現方法は、後から考えたらいいです。

この回答へのお礼

参考になる情報を教えて頂いてありがとうございました。

もう少し画面の構成を考えてみます。

お礼日時：2015/01/15 09:55

No.8 回答者： f_a_007 回答日時： 2015/01/14 12:29

×　明細行に諸情報を転機して検索フォームを開く。

〇 明細行に諸情報を転機して検索フォームを閉じる。

この回答へのお礼

ご回答ありがとうございます。

気づいたことがありましたので・・・

>受注情報管理----商品マスター管理に相当
>見積り-----------見積書に相当
>工事依頼---------売上伝票に相当(※)

※　工事依頼は、原価になります。
　売上伝票というからには、原価ではなく、売値と言う意味ですよね？
売上は、見積書に書いた金額の合計です。見積は、依頼元に出す見積です。これが売上です。

疑問が解決出来ないです。

お礼日時：2015/01/15 12:14

No.7 回答者： f_a_007 回答日時： 2015/01/14 12:26

【補足】受注、見積り、工事依頼の関係はシンプルに。

受注情報管理----商品マスター管理に相当
見積り-----------見積書に相当
工事依頼---------売上伝票に相当

ですから、見積書の[見積書][見積明細]というメインとサブフォームを持つフォームで入力し、対応したテーブルに発生時点で登録するだけだと思いますよ。現に、会社には見積書綴りが発生順に閉じてありませんか？そして、この場合も、(1)相手がある、(2)月報がある。などで、[見積明細]には区分が発生します。

http://www.officezero.info/zeroce/help/200937201 …

　↑
[行番号][区分][コード]・・・・

の並びが、いわゆる伝票明細の基本です。

なお、商品コードを空値にしたら⇒商品検索フォームが開く⇒商品を選択する⇒明細行に諸情報を転機して検索フォームを開く。この商品検索フォームでは、「何らかの検索用情報の入力」⇒「該当する商品」、「該当する商品枝番」の一覧表示。かつ、それぞれの枝番の在庫状況（見積状況）も表示することになります。

こういう風にシンプルに考えたがよいかも知れません。

この回答へのお礼

ご回答ありがとうございます。

工事依頼元へ出す見積もり書作成の場合、既に入力している部材注文一覧と仮工事発注一覧のレコードの項目名、単価、数量を受注IDで紐付けたもの全部使用したいのです。
その場合、クエリーでそうなるようなものを作成し、それをコンボボックスなどで選択するのも一つの手でしょうか・・・
そのレコードに、見積もり単価を入力すれば販売価格が決まると言う流れで・・・それを見積もりの親テーブルと明細テーブルに保存するという流れですね・・・に

お礼日時：2015/01/14 19:07

No.6 回答者： f_a_007 回答日時： 2015/01/14 12:03

全体のテーブル構造を私の粗末な頭が理解できるように若干修正しています。

この回答へのお礼

御礼が遅れましてすみませんでした。仕事の方が多忙になり・・・
丁寧なリレーション図、とても参考になりました。ありがとうございます。

お礼日時：2015/02/02 16:09

No.4 回答者： f_a_007 回答日時： 2015/01/14 09:29

＞多分無理でしょうか？

プログラム処理におよそ無理ってことはありません。

＞ある受注番号に対する部材の注文明細、
＞施工の発注明細の全レコードを一つの明細テーブルで管理したい。

これは、希望としては〇。だが、具体案としては×。理由は、添付図のような受注伝票入力フォームを超えることは不能だからです。例えば、添付図では[工事台帳].[行番号](工事No.）＝２を選択に対応した[工事台帳明細]を表示しています。こういう芸当は、メイン-サブの機能があって実現されます。また、そういう工事関係のデータとは無関係に[部材注文控]も受注に対応して管理可能。こういう仕組みは、リレーショナルデータベースならでは。それを崩すアイデアは×です。

＞そこから、複数の見積もりに分けたいのです。

それはそれ、これはこれです。

この回答へのお礼

Fa007さん

回答していただきありがとうございます。
データーベースの構造を無視したやり方はしてはいけないと言うことならば、受注のおや画面に二つのサブフォームを作り、それにそれぞれ、部材の注文明細、工事管理親フォーム、工事の発注明細のフォームを表示するやり方しかないと言うことと理解しました。

その場合、複数の請求先が発生する場合を考えて、各サブフォーム側の明細に請求先コードをセット出来るようにします。あと、見積もり単価もこのサブフォーム側に持たせないといけないでしょうね。

すると、請求先コードでフィルターかけて、見積もり作成をすれば、うまく行くとおもいますが、普通、このやり方でも問題ないのでしょうか？

うまくいきますでしょうか？

お礼日時：2015/01/14 11:13

No.3 回答者： f_a_007 回答日時： 2015/01/13 23:09

【補足】もしかして・・・。

受注案件一つに対し複数の工事が発生し、そして、そのそれぞれに内訳工事があるのでは？まあ、その場合でも、添付図のように【D】は無用です。

この回答への補足

fa007さん、
ご回答ありがとうございます。
一つの受注に対して複数の工事があり得ます。そして、そのそれぞれの工事に対して明細がつきます。

しかし、各項目を列方向に出したくありません。
部材の注文明細と、工事の発注明細のすべてのレコードを、一つの一覧にマージしたいのです。列めいは、見積もりようの列名にします。これを、マージ前の２つの明細テーブルに同期させられれば一番良いのですが、やり方がわかりません。多分無理でしょうか

ある受注番号に対する部材の注文明細、施工の発注明細の全レコードを一つの明細テーブルで管理して、そこから、複数の見積もりに分けたいのです。→精算処理→請求処理と、複数の請求先に対して出します。

一つの工事と請求先が対応してるとも限らないので、このようなやり方を考えました。

だから、selectは、使っても無理じゃないかと考えています。

補足日時：2015/01/14 00:09

No.2 回答者： f_a_007 回答日時： 2015/01/13 22:54

＜回答2/2＞

不必要な理由は、それはクエリで簡単に作成できるからです。

SELECT 受注台帳.ID, 受注台帳.受注日, 受注台帳.物件名, 工事台帳明細.行番号, 工事台帳明細.工事名, 工事台帳明細.単価, 工事台帳明細.数量, 工事台帳明細.摘要
FROM 受注台帳 LEFT JOIN (工事台帳 LEFT JOIN 工事台帳明細 ON 工事台帳.ID = 工事台帳明細.工事台帳_ID) ON 受注台帳.ID = 工事台帳.受注台帳_ID
ORDER BY 工事台帳明細.行番号;

結果は、添付図のようです。つまり、不必要だということです。

No.1 回答者： f_a_007 回答日時： 2015/01/13 22:47

＜回答1/2＞

Q、このやり方が良いのか？
A、不必要ですよ。

まず、添付図のような感じですと不必要。その理由は、回答=2/2で補足します。