過去の桐井戸端BBS (桐ver.7) |
699 | レポートでの集計作業 | 前田 | 1998/12/3-20:28 |
v7で次のような集計作業は出来ないものでしょうか。(変数を使用しないで) *売上の部門別集計で当月の売上と、その構成比の計算 食堂 筑波大学 600,000 千葉商大 600,000 当月売上 1,200,000 85.71% 年間売上 5,000,000 80.00% 売店 筑波大学 120,000 千葉商大 80,000 当月売上 200,000 14.29% 年間売上 1,250,000 20.00% 当月売上合計 1,400,000 100.00% 年間売上合計 6.250,000 100.00% 上記のようなレポートを一覧表で作成中ですが、小計、中計にはグループごとの総計と小計の集計関数しかなく、部門の集計値「当月売上」÷「当月売上合計」のようなことはムリでしょうか? 表の項目には「当月売上」と「年間売上」の項目は設定してあります。 直前値で集計を試みましたが、元の表が結合表のため直前値が使えません。 出来そうな気がしますが頭が追いつきません。どなたか名案はありませんでしょうか | |||
705 | Re: | ikjun | 1998/12/4-10:36 |
記事番号699へのコメント とりあえず、思いつきですが? >v7で次のような集計作業は出来ないものでしょうか。(変数を使用しないで) ホワイ?なぜ変数を使うといけないのでしょうか?すごく気になりますね。 レポートで変数を使用すると、結構便利です。 あえて使用してはいけない理由というのは、なにかバグがあるとかの情報があるのでしょうか? 単なる個人の趣味とか? > *売上の部門別集計で当月の売上と、その構成比の計算 >食堂 筑波大学 600,000 > 千葉商大 600,000 > 当月売上 1,200,000 85.71% > 年間売上 5,000,000 80.00% >売店 筑波大学 120,000 > 千葉商大 80,000 > 当月売上 200,000 14.29% > 年間売上 1,250,000 20.00% > 当月売上合計 1,400,000 100.00% > 年間売上合計 6.250,000 100.00% > 上記のようなレポートを一覧表で作成中ですが、小計、中計にはグループごとの >総計と小計の集計関数しかなく、 #項目値を忘れないようにしましょう。項目の値をそのまま出すという簡単な関数ですが、これをうまく使えば・・・・・ >部門の集計値「当月売上」÷「当月売上合計」の >ようなことはムリでしょうか? 問題は「当月売上合計」ですね。 これはレポートでは最後に出てきますから、あらかじめ計算しておく必要がありますね。 >表の項目には「当月売上」と「年間売上」の項目は設定してあります。 >直前値で集計を試みましたが、元の表が結合表のため直前値が使えません。 あらかじめ#直前値で集計できるように作ってある表に、読み込めばいいのでは? >出来そうな気がしますが頭が追いつきません。どなたか名案はありませんでしょうか 実際に、やってませんから、迷案のような気がしますが、こんな考え方はどうでしょうか? 要は、小計、中計の性格上、合計や平均などしかできません。それ以外ことはあらかじめ計算して、#項目値でそのまま印刷する。 あらかじめの計算は、とりあえず自分で考えて下さい。それを併合で印刷用のファイルに読み込めばいいと思いますが? 「タイトル: レポートでの集計作業」というのには反しますね。これにこだわるなら「不可能だと思います。」が答えでしょう。 わたしのつたない経験だと、印刷時に無理な集計をするより、あらかじめ計算してから、印刷するほうが、楽だと思うのですが?(桐に限らず) 仮にそのときは何とかなっても、ユーザーの要求によって修正がかかると途端に不可能になって、結局あらかじめ計算することになってしまう。 レポートの集計機能は、おまけくらいに考えたほうがいいです。 「入力」−>「処理」−>「出力」で考え方をわけたほうが、あとあと楽だと思います。 あまり参考にはならないかも知れないですね。こんな考え方もある程度です。 | |||
716 | Re: | 前田 | 1998/12/5-10:15 |
記事番号705へのコメント > 「入力」−>「処理」−>「出力」で考え方をわけたほうが、あとあと楽だと思います。 ありがとうございました。 結局私も数行の一括処理と、表の集計作業で事なきを得ました。 表記のようなことを思いついたのは、一つのレポートを作成終了した後に(あ!そういえばこの表にもう一つ別に出力してた表の集計部分を付けたい)別の作業を追加しようと思い集計機能を使いましたがどうもうまくいかなかった。..... 思いますに私のような専門職のプログラマーでなくても思いつきでどんどん作業が出来るのが桐の大きなメリットの一つだと思います。 | |||
718 | Re: | ikjun | 1998/12/5-11:08 |
記事番号716へのコメント 昔、(かなり前ですが!)コンピュータの処理が遅くて集計作業に時間がかかったときに、印刷するときに集計できれば、(特に昔はドットプリンタだったから)集計時間を気にすることなく、プログラムが組めると考えて、いろいろ工夫したことがあります。(財務会計の試算表だったのですが!) そのときも結局、苦労した割には報われなかった経験があります。 基本的に印刷の順番と集計の順番は必ずしも一致しません。 それを無理に集計しようとしても思った通りにいかないのが問題ですので、このやり方は勧められません。 (うまくいく場合もあるのですが!) >思いますに私のような専門職のプログラマーでなくても思いつきでどんどん作業が出来るのが桐 >の大きなメリットの一つだと思います。 そうですね。ただ、そのやり方はドツボにはまると、抜け出せなくなるという欠点もあります。 「入力」−>「処理」−>「出力」がプログラムの基本中の基本というのはプログラム設計の本の一番最初に書いてあることですし、困ったときはそこにもどるという考え方をもっていると結構助かったりします。 桐だけじゃなく、プログラムにはまるというのは、結局ここを忘れている場合が多いような気がします。 (もちろん、応用はこんな簡単なことでは表現できないのですが!) たまには、やさしいプログラム設計の本でも読んでみると、以外と参考になることがあります。 わたしは、桐の良さというのはシステム設計をちゃんとすれば、細かいことを気にせずに素直に書いていけばいいという点だと思ってます。 細かいことを気にしなければ、その楽さは他のソフトの比ではありません。 (ただ、細かい制御は弱いなあ?とも思いますが?) ちなみにわたしの理想は、いわゆるコーディングという作業がまったくなく、システム設計書がそのまま動くというものなのですが(^^;) まあ、自分のことを棚にあげての話ですので、あまり気にしないで下さい。 |