みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
現在、納品書とそれに紐づく在庫倉庫の管理に関する情報を組んでいます(Filemaker Pro 13 Mac)。
在庫レコードは
商品ID:倉庫:入庫:出庫
納品書には
商品ID:倉庫:数量(出庫数)
があります。
倉庫への入庫は、入庫用のオペレーションがあって、例えば、
1:東京:100:(空白) :
といったデータが入ります。
納品書はまた別のオペレーションで、
1:東京:100
2:大阪:200
といったデータになります。
この納品のオペレーションの際に、同時に入出庫のテーブルに
1:東京:(空白):100
といったデータを入れたいと思ってます。
全体としては、入出庫のテーブルに
1:東京:100:(空白)
1:東京:(空白):100
1:大阪:200:(空白)
2:東京:100:(空白)
2:大阪:300:(空白)
2:大阪:(空白):200
といったイメージを描いています(他に日付も入りますが、ここでは、参考程度です)。
とりあえず、
* リレーションで、入出庫::商品ID=納品書::商品ID、入出庫::倉庫=納品書::倉庫
* 「このリレーションシップを使用して、このテーブルからのレコードの作成を許可」をON
* 入出庫::出庫のデータを納品書::数量からルックアップ
という作業をしています。
ところが、こうすると、出庫の数量が単純に入庫数に入ってしまうだけで、レコードの追加になりません。
1:東京:100:100
といった、誤ったレコードができてしまいます。
これは、どうしたらいいでしょうか? どういう形で「あるテーブルの追加から別テーブルの行の追加を作成する」ということができるでしょうか?
よく分かっていないけど
納品データを在庫テーブルにインボートしたらいいのでは。
Offline
旅人さんの通り、インポートでいいですね。
その場合、
ルックアップはしてはいけませんね。
もうひとつの方法、
納品書でシリアル番号等、ユニークな値を持たせて、
入出庫でも同様のフィールドを作り、リレーション。
新規レコード作成時に
入出庫::適当なフィールド
に入力でレコード作成が出来ます。
これはスクリプトで自動化できます。
他はルックアップ。
Offline
ありがとうございます。
インポートでほぼやりたいことは達成できました。これもスクリプト化できそうなので、それを軸に試行錯誤したいと思います。
同様なリレーションも考えてみます。
インポートのスクリプト化およびレイアウト移動時のトリガで成功しました。
インポートする様な構造は宜しく無いと思いますが。伝票作成後に変更が出れば、動きが非常に煩雑になります。
出庫は、納品以外にもあるならまた別の話として。（例えば倉庫間の移動など）
入庫伝票 在庫テーブル
入庫番号 ＝ 入庫番号
日付 → 日付
商品ID
倉庫
入庫
納品伝票 在庫テーブル
納品番号 ＝ 納品番号
日付 → 日付
納品先 商品ID
倉庫
出庫
という構造にします。それぞれの伝票テーブルの中で、在庫テーブルをポータルで表示しておけば、そのまま入力するだけで完了します。在庫テーブルの中で一元管理が可能です。
Offline
ありがとうございます。
ただ、実を言えば、「在庫テーブルの管理」をしたいのではなくて、「納品書のデータを反映させたい」というのが質問の主眼なのです。納品書はあくまで納品書として作成して、それを確認、修正のため、保存します。また、説明ははしょりましたが、上記データは既に納品のヘッダと明細に分かれていて、オペレーション上は明細をポータルとして使っています。今のところ、納品番号と明細番号を一意なキーとして、データをインポートすれば、変更は反映、新規は追加(SQLのupdateの操作に近い)で機能すると考えています。
おっしゃる通り、インポートはデータ構造に強く依存するため、今後の修正等に影響を及ぼす可能性も感じています。
そういうわけで、いい方法を探しています。
明細のテーブルを共有させるだけの話で、内部では明確に分離できます。一度実証してみられれば良いでしょう。
それだけで構造的に格段に良くなり、今後の展開が自由になります。将来的に必ず在庫管理を行う事になるでしょうが、その時に明細テーブルが入出庫データそのものになり、納品書とのデータの乖離も有りませんので，理想的な構造になるはずです。
「インポートはデータ構造に強く依存する」のではなく、同じデータが違うテーブルに2重に存在する事が、DBの理論的に間違っており、運用上も煩雑な動きが必要になります。
この構造を強くお勧めしますよ。
在庫管理は金輪際行なわない、というのでしたら、別々のテーブルにしておいても良いと思いますが。
Offline
[ Generated in 0.004 seconds, 9 queries executed - Memory usage: 516.33 KiB (Peak: 520.87 KiB) ]