ACCESS2010 製品管理をしたいのですが。

質問

今、製品管理を作ろうとしているのですが。
わかりません。　とりあえずこう考えています

製品Ａを作るのに　ワッシャ１　ボルト１　ナット２使うことにします
そうすると、　ワッシャ１　ボルト１　ナット２が部品在庫から減りますよね
製品Ａをたとえば５００個作る時　自動的に部品が減るようにするにはどうすればいいですか？

なんか　ごちゃごちゃになってわけわからなくなってきました。

回答No.5

naoto0216

#4です。補足です。
フォーム「在庫管理」に製品名を入力させるように記載しましたが
実際には、コンボボックスに製品マスターの製品名を表示させ
選択できるようにします。

また、製品名が選択されたら、その製品では各パーツがいくつ
使用されるか分かるので、
＞入力された製品名と製品マスターを紐付けます。
は、不要です。

回答No.4

naoto0216

わたしだったら、以下の3テーブルを作成します。

製品マスター（どの製品にいくつのパーツを使用するか）
ID　製品名　ワッシャ　ボルト　ナット
1　　製品A　　1　　　　　1　　　2
2　　製品B　　2　　　　　2　　　4

製作履歴（いつどの製品をいくつ作成したかの履歴）
ID　製作日　　　　製品名　数量
1　　2015/06/29　　製品A　500

在庫（それぞれのパーツの在庫）
ID　ワッシャ　ボルト　ナット
1　　10000　　10000　　20000

フォーム「在庫管理」に
　・製作日
　・製品名
　・数量
を入力させ、「登録」ボタンがおされたときに、入力された
内容を製作履歴テーブルに登録します。
また、製品名から各パーツの必要数を算出する為に
入力された製品名と製品マスターを紐付けます。

例えば、製品A、500と入力されたら、製品マスターで
製品Aの各パーツの使用数がわかるので、

　ワッシャ　500×1　＝　500
　ボルト　　500×1　＝　500
　ナット　　500×2　＝　1000

と計算し、更に在庫テーブルの各パーツから上記で
算出した個数を在庫数から引きます。

　ワッシャ　10000-500　＝　9500
　ボルト　　10000-500　＝　9500
　ナット　　20000-1000 ＝　9000

ザックリだとこんな感じでしょうか。

お礼

遅くなりました、
今回は、細かいところまで教えていただきありがとうございます
印刷させていただきました。これから、構築していくために
活用させていただきます
また、わからないことがありましたらご相談させていただければと
思います　よろしくお願いいたします

取り急ぎお礼まで　ありがとうございました

回答No.3

noname#231195

そのような目的にはクエリを使います。
考え方としては、ある在庫の初期値だけがデータとしてデータベースに保存されていて、その初期値の時点以降の使用数をいちいち計算して、初期値から引き、現在の在庫を表示するという風にします。
在庫の初期値はいつの時点での初期値でもいいですが、たぶん期末の棚卸の時点とかにするといいのではないでしょうか。
なお、部品が納入されて在庫が増えるのも同じです。在庫の初期値に、納入数を足して現在の在庫を表示するというふうにします。

ただ、いきなりクエリを作るのではなく、目的に合ったテーブルを作るのが第一段階です。ということで、まずはテーブルづくり。一例にすぎませんがこんな風に3つのテーブルを作っておくことができます。

tbl製品製造実績
製造ロット番号：もちろんロット番号でなくても日付で管理するならそれでもいいです。とにかくその製造数の数だけ作る、そのまとまりを特定する情報です。時系列にあとのロットが大きい番号を持つようにしておきます。主キー。
製品番号：出来上がった製品の製品番号。
製造数：

tbl構成部品
ID：オートナンバーで連続する番号を与えておく。主キー。
製品番号：。
部品番号：使用する部品の部品番号。
必要数：その製品を作るために必要なその部品の個数。
#このテーブルでは一つの製品-部品の組み合わせが一レコードになります。製品Aにワッシャ１、ボルト１、ナット２が必要なら、
製品A-ワッシャ
製品A-ボルト
製品A-ナット
の3つのレコードをこのテーブルに書いておくことになります。

tbl部品リスト
部品番号：主キー。
在庫初期値：例えば棚卸した時の在庫数。

ご質問の機能-つまり現在の在庫数のリストを作る-を実現するためにはとりあえずこれだけでいいはずです。
実際には例えばtbl部品リストには部品の名前だとか、価格だとかいろいろ他の情報も入ることになるんでしょうが、これは追い追いフィールドを足していけばいいです。

で、次に目的の現在の在庫数を求めるクエリを作ります。ただ、いきなり在庫の一覧表を出さずにまず準備段階として各製造ロットでどれだけの部品を使ったのかというクエリを作っておきます。qry部品使用数という名前とすることにします。

クエリビルダにどうクエリを作るか文章で書くことができないので、ここにはSQLを張っておきます。
このSQLをお手元でアクセスのSQPビューに張って、クエリビルダのビューに切り替えてごらんになってください。アクセスの吐きだしたたSQLをそのまま張り付けていますので、エラーはないはずです。
SELECT tbl製品製造実績.製品番号, tbl製品製造実績.製造ロット番号, tbl製品製造実績.製造数, tbl構成部品.部品番号, tbl構成部品.必要数, [製造数]*[必要数] AS 使用数
FROM tbl製品製造実績 INNER JOIN tbl構成部品 ON tbl製品製造実績.製品番号 = tbl構成部品.製品番号;

で、やっと次に現在の在庫のリストを作るクエリにたどりつきます。このクエリをqry部品在庫という名前にしておくことにします。
これもSQLを張り付けておきます。
SELECT tbl部品リスト.部品番号, tbl部品リスト.在庫初期値, DSum("使用数","qry部品使用数","部品番号='" & [部品番号] & "'") AS 使用数総計, [在庫初期値]-[使用数総計] AS 在庫数
FROM tbl部品リスト;

それぞれのテーブルとクエリのイメージは画像として張り付けておきます。
見えますかね？

お礼

遅くなりまして申し訳ありません
やっと、時間がもてましてアクセスの構築を進めております
今回は、細かいところまで、またイメージ画像も送っていただき
大変感謝しております。　印刷させていただき　これからの構築で
活用させていただきます。　また、わからないことが出てくるのと思いますので
その時はまた　よろしく願いいたします

取り急ぎお礼まで

回答No.2

山田 太郎（@f_a_007）

【直接的な回答に代えて！】

現時点では、直接的な回答を示すことは質問の曖昧さが大きいのでできません。ですから、基本的な考え方のみ。

１、低レベルのテーブルアクセスで関係列を更新しなくてもよい。
２、安直にSQL文を発行しても構わないのでは・・・。

留意点

１、Accessシステムでは、テーブルに列[現在庫数]を設けることはしない。
２、Accessシステムでは、[現在庫数]=[月初在庫数]+[入庫数]-[出庫数]で求める。
３、月締めとデータ入力を同時に行うためには[前月在庫数][前月入庫数]-[前月出庫数]も記録する。

課題

１、データ入力時に、フォームに各副材料の現在庫数をいかに表示するのか？
２、データ入力の終了時に、各テーブルの[仮出庫数]をいかに更新するのか？

質問は、この課題２に関するものと仮定すると私の回答は冒頭の２点。

お礼

遅くなりましたがコメントありがとうございます
やっと時間があきましたのでアクセスに取り組んでおります
細かく教えていただいたので　いったん印刷させていただき
活用させていただきます。
また進めていく中で　わからないことがありましたら
教えていただければうれしいです

取り急ぎお礼まで　ありがとうございました

回答No.1

山田 太郎（@f_a_007）

＞今、製品管理を作ろうとしているのですが・・・。

この製品管理って代物の目的・意義・必要性などの明確化が先決。

＞製品Ａをたとえば５００個作る時　自動的に部品が減るようにするにはどうすればいいですか？

こういう＜自動在庫引落しの仕組み＞を誰がどのように利用するのか？
また、かかる＜自動在庫引落しの仕組み＞の目的・意義・必要性は？
更には、実際の在庫管理システムとの兼ね合いは？

＞なんか　ごちゃごちゃになってわけわからなくなってきました

それは、当然のこと。

１、現行の在庫管理の仕組みの分析。
２、現行の指図処理（受注処理）の仕組みの分析。

分析とは：

関連部署の業務を可能な限り細かい部品にバラして非本質的なものと本質的なものとの峻別を通して抽象概念としても次世代業務像を取得する。その上で、(1)捨てるべきもの、(2)形を変えて継承すべきもの、(3)新たに置き換えるもの等を明らかにして、抽象概念を具体的な次世代システムとして組み立て直す。

こういう業務のバラシと再組み立てのプロセスが先ですよ。

【システムの基本は１＋１＝２】

10 input A, B
20 C=A+B
30 print C

およそ、質問者が企図している「製品管理」だって、その基本は、(1)データ入力、(2)データの処理、(3)処理結果の出力の３つの機能で構成されます。だとするならば、

(1)　誰がいつどのようなタイミングでどのようなデータを入力するのか？
(2)　そのデータをどのように処理するのか？
(3)　処理結果は誰のためにどのようなタイミングでどういう形で出力するのか？

ってのを明確にする必要があります。

【受注・指図システムにおける在庫自動引落しの意義と限界とは？】

さて、在庫管理は在庫管理であって受注・指図システムにおける在庫自動引落しは在庫管理そのものではないことは明らかです。そして、この両者を密接不可分・表裏一体のシステムとして設計することのリスクってのも考慮する必要があります。運用上のリスク、メンテナンス場のリスクetc.。

さて、そういう色んな検討を経るならば、「受注・指図システムにおける在庫自動引落し＝在庫仮想引落しシステム」という結論に至るかも知れません。

Q、製品Ａをたとえば５００個作る時　自動的に部品が減るようにするにはどうすればいいですか？
A、そういう手の問題は、全体のシステム設計が終了した後の細かい細かい問題に過ぎません。

例えば、[製品台帳]や[主材料台帳]等のいわゆるマスターテーブルの設計も、(1)データ入力、(2)データの処理、(3)処理結果の出力の３つの機能のあり方で大きく異なってきます。在庫管理システムのそれと受注・指図システムのそれでは運用目的が全く違います。

言えることは、今はAccessを起動させてその画面を眺める段階ではないってことです。Word等で

１、業務のバラシと組み立てのレポートを作成する。
２、次世代システムの全体像と意義・目的をまとめたレポートを作成する。
３、次世代システムの入力画面と各種レポートの雛形を作成し回覧する。

で、OKがでたら・・・。

４、更に、テーブル設計書を書きあげる。
５、入力画面と各種レポートの最終案を仕上げる。

ここまで詰めてから、やーっとAccessを起動して実際のシステム開発に着手します。とにもかくにも、急ぎ過ぎで無謀ですよ。

テーブル：製品台帳

ＩＤ＿＿＿＿＿＿:　1,2・・・N
製品名＿＿＿＿＿:　製品名A
区分＿＿＿＿＿＿:　A群
主材料＿ＩＤ＿＿:　1,2・・・N
副材料１＿ＩＤ＿:　1,2・・・N
副材料２＿ＩＤ＿:　1,2・・・N
副材料３＿ＩＤ＿:　1,2・・・N

テーブル：主材料台帳

ＩＤ＿＿＿＿＿＿:　1,2・・・N
製品名＿＿＿＿＿:　製品名A
区分＿＿＿＿＿＿:　A群

テーブル：副材料台帳

ＩＤ＿＿＿＿＿＿:　1,2・・・N
製品名＿＿＿＿＿:　製品名A
区分＿＿＿＿＿＿:　A群

補足

たんなる会社で使おうかなと思っているだけで
そんな難しく考えていませんけど。
たんなる製品管理です。