みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
ある業務の請負をしており売上を管理するため
売上テーブル（日付、業務概要、請求先など基本情報と詳細にある金額の小計）
詳細テーブル（細かい作業内容や個々の金額、担当者など）
で親子関係（1対多）でつくりました
実際のフォームのイメージは
日付 11.1 請求先 S社
業務概要 ○○業務
金額 20000
======================
作業内容 金額 担当者
AAAAA 5000 001
BBBBB 5000 001
CCCCC 10000 002
次のレコード
日付 11.2 請求先 S社
業務概要 ○○業務
金額 10000
======================
作業内容 金額 担当者
AAAAA 5000 001
BBBBB 5000 002
です
請求書を発行するときにはリスト表示で売上テーブルを明細として
日付 業務概要 金額
11.1 ○○業務 20000
11.2 ○○業務 10000
と並べて、一覧にすることはできました
別途、詳細テーブルの、担当者についても担当者ごとにリスト化するにはどうしたらよいでしょうか？
上記詳細の金額を担当者ごとに小計して、下記のようにしたいです
日付 内容 金額 担当者
11.1 ○○業務 10000 001
11.1 ○○業務 10000 002
11.2 ○○業務 5000 001
11.2 ○○業務 5000 002
そして上記の1行を1レコードとして、他のレコード（別テーブルにある別業務のレコード）と
まぜたリストを作り、実績表としたいです
詳細テーブル側で、日付、業務内容、担当者で集計すればいいですよ。
ちなみに、
日付 業務概要 金額
11.1 ○○業務 20000
11.2 ○○業務 10000
も、詳細テーブル側で、日付、業務内容で集計すればいいです。
Last edited by Shin (2022-11-09 13:28:42)
Offline
回答ありがとうございます
リスト形式の集計パートを使うということですか？
別テーブルにあるレコード、といいていましたが、まとめ詳細テーブルに格納するように変更して
その集計しないレコードは集計有無を判別するフィールドを作っておき
集計パートをスルーさせる、とかでいいのでしょうか？
単純に、詳細テーブルの集計レイアウトを作るだけでいいんですが
＞詳細テーブル側で、日付、業務内容で集計
のために、集計グループのフィールド（日付、業務内容）を詳細側にもルックアップで入れておく必要があるかな。
＞そして上記の1行を1レコードとして、他のレコード（別テーブルにある別業務のレコード）と
これは意味がわかりませんが「別テーブルにある別業務のレコード」とは何ですか？
全く別のシステムが存在する？
業務が別だからといってテーブルやファイルを別にするのはシステムとしてよくないですが
請負じゃない業務ってことか？？？それならありえるか...
集計行だけ取り出すのは、レコードのエクスポートでできます。それを別システムにインポートすればよさそうな感じ？
Offline
himadaneeさん
集計レイアウトで集計しても、それがレコードの形で残らないので
様々な部分で使ったり再計算するのに不便ではないですか？
その意味で1対多の親がわのようにレコードに残る形にしたいです
Shinさん
請求 のレイアウトでも集計でやるものなのですか？
そのまま業務テーブルのレコードをリスト表示するのと違いがありますか？
今回は、わけがあってあえてそうしている、ということでしょうか？
ならば、
担当者ごと ＆ 日付ごと
を1レコードとする別テーブルを作ればいいでしょう。
集計をするのに、
小計パート・集計フィールドを使った集計レイアウトを使うか、
リレーションを使って統計関数で集計
主にこの二つの方法がありますね。
どちらにするかは、その集計値をどう使うかとか、
レイアウト等で決めればいいでしょう。
設定はどちらも簡単ですから、両方試してみればいいのでは。
Offline
入力としては
親としての売上テーブルに基本を
子としての詳細テーブルに担当者や金額をいれます
すると売上IDに紐づいた詳細レコードが、詳細テーブルに記録されます
これにどうやったら、担当者ごと ＆ 日付ごとのテーブルにも追加されるようにできますか？
集計レイアウトで集計しても、それがレコードの形で残らないので
様々な部分で使ったり再計算するのに不便ではないですか？
その意味で1対多の親がわのようにレコードに残る形にしたいです
集計はほぼ一瞬で終わってしまうので、不便はないです。逆に、そのソリューションを10年運用するとして、10年前の一覧表を頻回に週1とかで参照しますか。一覧表を保存しておくエリアが無駄に思います。また、集計叛意も、週単位、月単位、4半期、半期、年度、などを要求されることもありますが、それぞれに表を保存しておくと、10年で800弱になります。それがよければ、保存する運用を選ばれればいいと思います。（その中から探し出すのも面倒では）
請求 のレイアウトでも集計でやるものなのですか？
会社にもよるでしょうが、毎日複数回の発注がありその度に数十件、とかもあります。1請求ごとに明細が数千行になりますが、集計リスト以外でどうやって出力しますか。
また、集計機能を使っておくと、近い締め日の複数の取引先の処理を1操作でできますので、大きな時間短縮になります。
その範疇でないのでしたら、どちらで作業されてもいいのでは。月に1件の請求ならば、何でやっても同じです。
そのまま業務テーブルのレコードをリスト表示するのと違いがありますか？
今回は、わけがあってあえてそうしている、ということでしょうか？
業務データから、明細を区分することはできませんね。企業によっては、品目や区分ごとで分類した上で、日付ごとの明細を、という型式を求められることもありますが、明細側での集計レイアウトならば簡単に対応できます。
Offline
1対多にしての部分のまとめられたレコード（詳細などの合計値や一注文や一日などの単位ごと）に対して
取引先や日付などでフィルタリングして請求書をつくると思っていましたが
そもそもの考え方が間違っていたのでしょうか
基本的に集計パートでやるものなのですね
まったく集計パートをつかっておらず
なんなら使いにくいとすら思っていたので根本から勉強する必要がありそうですね
チポさんのおっしゃっているやり方はまた違ったアプローチなのでしょうか？
> 担当者ごと ＆ 日付ごとのテーブルにも追加されるようにできますか
このテーブルで、
入力値の自動化で
担当者 ＆ 日付
とするフィールドを作り、
入力値の制限で
常時・ユニーク
とします。
これで詳細をインポートすれば、
担当者 ＆ 日付
が重複することなくレコードが作られます。
予断で決めつけるより、
ご自分で試されることをお勧めしますよ。
やり直しも簡単ですから。。
Offline
集計の考え方は、集計機能とリレーションによるものの2通りあります。結果は同じなので、お好みを使われればいいとおもいますが。
> 1対多にしての部分のまとめられたレコード（詳細などの合計値や一注文や一日などの単位ごと）に対して
そもそものこれを再考されたほうがいいと思います。
卸会社の一昔前の紙伝票の処理を考えてください。
受注伝票を作ります。その紙一枚に複数の行が存在して、受注品が並んでいます。発送するためにピックアップしますが、その日の受注束を持ち出して、1伝票ごとに倉庫をぐるっと回るか、1区画ごとに全伝票を1枚ずつ繰って商品があるかどうかさがして倉庫を一回りしてきますね。
もし、1受注ごとの受注品を1明細ごとの伝票として作成していたらどうでしょう、ピックアップの前にその伝票の商品で区分けしておき、倉庫の区画順に並び替えておけば、倉庫をさっと一回りすればその日の出荷をピックアップできます。それを出荷先ごとにまとめて出荷です。
また、1年分などの集計を行う場合、1明細ごとの伝票があれば、すべての伝票を商品で区分けし、それを発注元ごとに分類して、数を数える、が簡単ですよね。1受注複数明細でしたら、1枚ずつ繰りながら、別の集計用紙に書き写すしかないでしょう。仮に、その中間的な集計したデータ（1日単位とか商品ごととか）を作るとしても、その中間的なデータを保存する場所が必要です。1日にのべ100品目あるとすると、年で3万レコード必要になり、区切り単位ごとに必要でしょうから、週ごと、月ごと、半期ごとなどにレコードを作っていくと、年に4万レコードになります。それを集計する手間は紙の運用でしたら手間は減るかもしれませんが、データベースでは、区分けや並べ替えは非常に得意なので、その中での作業はほぼ瞬時で、全体を集計しても部分的に集計してもほとんど変わりません。さらに、もし過去の数値に修正が入れば、そのレコードの修正の手間も増えます。
その区分けを行う際に使う機能が、集計かリレーションです。
集計は、全部を並べてしまい、その区切りで数を数えます。私がサンプルファイルで使っている手法です。
リレーションは、明細に付箋を貼るイメージで印をつけておき、それをピックアップして数を数えます。チポさんが説明している手法です。
少し動きが違いますので、目的に応じて選択されるといいでしょう。
Offline
Pages: 1
[ Generated in 0.008 seconds, 9 queries executed - Memory usage: 599.27 KiB (Peak: 616.18 KiB) ]