みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
一つのポータルでふたつのテーブルに入力したいのですがうまくいきません
このような感じでよいでしょうか？
親テーブル
子テーブル
孫テーブル
となっていて、
親 子 孫
親ID=親ID=親ID
子ID=子ID
でリレーションしています
親テーブルのレイアウトに子のポータルを配置し
そのなかに子のフィールドと孫のフィールドを配置しています
各IDはオートナンバーにしていて、少し入力した限りでは
親子孫ともにレコードが追加されていて問題ないように感じますが
間違いはありますか？
その構造では、子対孫は、1対多に対応できません。
1対1なのでしたら、孫テーブルの存在意味がないです。
また、そのポータル内では、子テーブルのデータを入力して、一度確定させてからでないと孫データの入力はできないはずです。入力順が制限されますが、明示されていないので、レイアウトの構造としては良くないです。
Offline
1つの伝票に複数の注文がはいり、その注文ごとに担当者がいます
親が伝票
子が注文
孫が担当者
です。それらを入力して、取り出したいデータは
2023/07/30 伝票番号00001 注文額10000円
で、これは親子関係で出すことができます
もう一つ
2023/07/30 担当者 AAAA 発注額(注文額のこと) 10000
というのもだしたいです
そこで質問の通りの構造にしましたが、ご指摘のとおり
意味のないテーブルかつ入力順も制限されてしまいますね
親と子だけにして親からみれば
2023/07/30 担当者 AAAA 発注額(注文額のこと) 10000
をつくれるのに気が付きませんでした
例が1件だけではわかりにくいですが、
日ごと担当者ごとの合計発注額を出したい、ってことでしょうから、「親からみれば」でなく「子のレコードを集計すれば」ではないですか。
今はExcelで入力していて
コピペで伝票、注文、担当シートに貼り付けています
それにより、担当者ごとに月計や日計をだしたり
伝票の宛名ごとに月計したりしていです
そもそも集計したい（複数のレコードを日単位や月単位として扱いたい）
だけなので、親テーブルすら不要で、
子に集計フィールドをつくればいいことなのでしょうか？
一対多を簡単にやるのが集計フィールドという機能なのでしょうか？
伝票-注文のテーブル構造は、入力時に必要でしょう。これが無いと、複数注文時に面倒です。
顧客ごとの集計は、単なる金額合計なら注文テーブル側でもできます。ですが、日毎明細や注文品種ごとの集計はできません。
集計は、原則明細側(注文側)のデータで行います。そこに必要に応じて、注文数のカウントや金額合計する集計フィールドを作ります。
別のレイアウトを作り、集計のキーとなるフィールドをキーとする小計パートを作っていきます。
Offline
詳しい解説ありがとうございます
明細書をつくるとしたら、集計フィールドを表示させて印刷することになると思いますが
抽出したものに追加でレコードを増やしたい場合（集計値としてでなく、別途割増、などです））は
都度伝票テーブルと連携した明細テーブルに追加して
再抽出という感じでしょうか？
うまく伝えられませんが
いきなり孫テーブルにデータをいれたい場合があるんですよね
普通はそれでも伝票（ダミー）からつくるものですか？
＞1つの伝票に複数の注文がはいり、その注文ごとに担当者がいます
なので、「いきなり孫テーブルにデータをいれたい」＝注文なしに担当者を入れたい場合というのは矛盾してます。
「すべての注文が同一担当者の場合は注文でなく伝票に担当者を持たせたい」、ならば、伝票テーブルにフィールドを作るのが普通では。
孫の出番はなさそうです。
#7の「別途割増」の方は、伝票１つでなく複数の伝票をまとめて請求とかする時に発生するものではないですか？
それなら伝票とは無関係に請求のテーブルの出番のような。親子孫とは別です。（叔父？）
伝票1つごとのものであれば、明細に入れるでしょう。
具体定期に、どの様な業務を行なっているのですか。担当者から入力を始める構造も作れないことはないですが、少し複雑になります
Offline
Pages: 1
[ Generated in 0.005 seconds, 9 queries executed - Memory usage: 563.83 KiB (Peak: 579.09 KiB) ]