日次データの表紙(6)

次々といろんな帳票を作る必要が出てきて、なかなか更新できません(^_^;)
その代わり、ネタはたくさんできてます。
表紙データは今回でひと段落です。ただ、この後でいかに自動化するかでかなりてこずりましたので、それはもう少し経ってからご報告する予定です。

私が休んだときに、FileMakerのことをほとんど知らない他の人に作業をやってもらう必要があるので、簡素化に簡素化を重ねてかなり簡単にしました。普段、自分でもあれこれいらうので、カスタムメニューにせずに、それでいて余計なところを触らせずに、簡素化するというのかかなりのもんでした。はい。

さて、今回は粗利(厳密に言うと違うそうなのですが、うちの会社ではそう呼んでいる)
数字の出し方です。

要するに、

売上ー原価

です。

SQLとしては、売上と同じものです。
 ↓を参照ください。

日次データ用の表紙(1)

今回使ってる部分は売上金額と原価金額と原価区分がメインです。
原価区分というのは、製品によって、国内生産、海外生産、部品と3種類に別けて考えているので、原価区分に1、2、3と数字を入れてあります。その区分ごとに集計して、それぞれ売上から引いた金額を出して、レイアウトに貼り付けます。

arari_table

画像でデータ処理日がグローバルフィールドになっているのが、今回の肝です。
これは売上の時にも大事な処理だったのですが、書き忘れてました。m(__)m

現行のシステムの課題なのですが、金曜日に受注の入力をするときに、土曜日が休みの場合でも、デフォルトで土曜日の売上としてあげてしまいます。
それだと困るので、売上日を変更して受注の入力をするのですが、人間がやることなのでどうしても土曜日に売上が立ってしまうことが起こります。
そこで、休み明け(主に月曜日)には、日にちの範囲を絞り込んでデータを抽出します。

たとえば、

20060114...20060116

として、読んできたデータを絞り込みます。

ところが、日にちをリレーションのキーにしているので、これだと合計金額を出すことができません。
そこで、「データ処理日」というグローバルフィールドを追加して、絞り込んだデータに自動的に休み明けの日(この例では、20060116)の数字を入力するようにしました。そして「データ処理日」(例で言えば、20060116)の値をキーにして、リレーションをはるようにしています。

ちなみに、当たり前のことですが入金、支払、仕入については、当日に処理しますので、上記のように休みに数字が上がることがありませんから、日にちをそのままキーとして使っています。

リレーションは↓画像のような感じです。

hyoushi_relation

| | コメント (0) | トラックバック (0)

日次データの表紙(5)

1年越しの更新です(^^ゞ
さて、前回入金についての説明でしたので、今回は支払いについてですね。
支払いは、読み込んでくるテーブルが違うだけで、入金と全く同じ仕組みを使います。

図のように、取引区分名と区分でリレーションかけて

Sum ( 仕入読込用::支払金額 )

として、現金、小切手、振込、手形・・・など各仕訳ごとに合計金額を出します。

shiharai_relation 

念のためSQLを記しておきます。
毎度無駄の多いSQLですが・・・m(__)m

SELECT
"購買テーブル"."伝票区分",
"購買テーブル"."購買NO",
"購買テーブル"."行NO",
"購買テーブル"."購買日付",
"購買テーブル"."仕入先コード",
"購買テーブル"."支払先コード",
"購買テーブル"."仕入先略称",
"購買テーブル"."取引区分コード",
"購買テーブル"."取引区分名",
"購買テーブル"."商品コード",
"購買テーブル"."商品名1",
"購買テーブル"."商品名2",
"購買テーブル"."仕入数量",
"購買テーブル"."仕入単価",
"購買テーブル"."仕入金額",
"購買テーブル"."税抜仕入金額",
"購買テーブル"."仕入消費税額",
"購買テーブル"."支払金額"
FROM"購買テーブル"
WHERE"購買テーブル"."購買日付">=2006****

おそらく、これも半分くらいのフィールドを読み込めば済むと思います。順次見直しをかけて行く予定です。たぶん1年後くらい・・・(^^ゞ

ところで、入金のときに書き忘れましたが(こんなんばっかですみません・・・)、日にちの指定の仕方にかなり悩みました。

1)いちいちスクリプトを開いてSQLを書き直す
2)FileMakerのスクリプトからSQLに日にちを渡す
3)SQLでtoday関数のようなものを使って日にちを特定する

などなど・・・

1)インポートするためのSQLを、毎日いちいち全部開いて書きなすというのは、間違えも多そうですし、第一むちゃくちゃ手間かかるので却下です。

2)は、調べた限りできそうもありません。

3)は、そんなSQLあるんですか?・・・(^^ゞ(今後の課題)
もしあったとしても、テキストフィールドに、例えば20060116とあるだけなので、これを日にちとして認識させるか、関数で出してきた日付を同じ形式のテキストに変換するかの作業をしないとならないはずなので、現時点ではギブです。

で、いろいろと考えた結果、今の自分の力でできる方法として、

何日以降ということで、データを読み込んで、FileMakerの検索で必要な日にちを出して、それ以外を削除する。

という方法です。

この方法だと、2週間に1度くらいのSQLの日にち部分を変更するだけで済みます。
また、検索して結果を表示させるだけでも良いのではと思ったのですが、リレーションで合計をもってくる時に結果がうまく出なかったので、必要な日にち以外を削除することにしました。(結果オーライ主義♪)

必要な日付以外を削除するスクリプトは、日にちを検索かけて>対象外以外を表示する>対象レコード削除という段取りなりますね。

後日分かった方法ですが、SQL Serverではselectの前に、下記のような変数が使えるそうなので、うまくやればもっと手間が減るかもしれません。やってみないと分からないですが・・・

declare

@BeginDate VARCHAR(8)

@EndDate VARCHAR(8)

Set @BeginDate='20060121'

Set@EndDate='20060220'

実は、今、基本情報技術者試験の勉強に行ってる学校の先生に教えてもらいました。活用できるものは、全て活用しないとですね(^_^)v

| | コメント (0) | トラックバック (0)

日次データの表紙(4)

前回、書くの忘れてましたが、SQL Serverの仕様か業務システムの仕様か、FileMakerの仕様か不明ですが、テキストフィールドを読み込むと、余分なスペースを読み込むのでちと難儀しました。なぜ困るかというとテキストフィールドをリレーションのキーとして使うとき、余分なスペースのためにリレーションがうまく機能しないことでした。
気づいてみれば、たいしたことなかったのですが、スペースが原因だと分かるまで結構悩みました。コードを使えばええやん!とツッコミ来そうですが、やっぱり数字だとスクリプトなどを見直すときに手間増えるので、あえてテキストを使用してます。はい。

なぜか同じ内容のものをODBC経由でEXCELで開くと、余分なスペースを読み込みません。同じマイクロソフト同士やから相性いいのか、FileMakerや他のDBソフトへの単なる嫌がらせか・・・?
まあ、どちらにしろ原因が余分なスペースだと分かれば、対応は簡単です。スクリプトに下記の関数を使って、読込でから余分なスペースを削除すればOKです。日常的に文字列操作によく使う関数です。

Substitute ( 売上日次一覧表::取引伝区分 ; " " ; "" )

入金の場合、入金の合計と、現金、小切手、振込、手形・・・など各仕訳ごとに金額を出す必要があります。しかし、これも前回と同様に別テーブルをつくって、取込データテーブルと区分でリレーションをかけて

Sum (売上日次一覧表::入金額)

とすれば出来上がりです。

nyukinmeisai

後は、前回と同じくポータルのフィールドを1つづつレイアウトに沿って並べていけばOKです。

苦労したのは、ポータルのフィールドを並べていくときに、限られたスペースに無理やり並べないとならないことでした。ポータル本体のフィールドから、ポータル内に配置するフィールドが少しでもはみ出してしまうと、結果が表示されなくなってしまいます。入る桁数を考えて、ある程度は広く取っておかないとなりませんし、矛盾する条件の元試行錯誤しながらなんとかうまく収めることができました。

さてSQLですが、下記のようになりました。

SELECT
"販売テーブル"."伝票区分",
"販売テーブル"."販売日付",
"販売テーブル"."取引区分名",
"販売テーブル"."販売NO",
"販売テーブル"."商品名1",
"販売テーブル"."商品名2",
"販売テーブル"."入金金額",
"販売テーブル"."伝票区分" +"販売テーブル"."販売NO",
"販売テーブル"."得意先略称"
FROM "販売テーブル","入金集計テーブル"
WHERE "販売テーブル"."伝票区分" +"販売テーブル"."販売NO" = '2'+"入金集計テーブル"."入金集計NO"
AND "販売テーブル"."販売日付" >= 2005****

今、見れば明らかにFROMとWHERE句に余計なものがありますね・・・(・_・;)
入金集計テーブルからは何も読み込んでいないのに・・・

実験してないので確証はないですが、ほんまやったら、↓で済むはずです。

SELECT
"販売テーブル"."伝票区分",
"販売テーブル"."販売日付",
"販売テーブル"."取引区分名",
"販売テーブル"."入金金額",
"販売テーブル"."伝票区分" +"販売テーブル"."販売NO",
FROM "販売テーブル"
AND "販売テーブル"."販売日付" >= 2005****

現状、問題なく動いていますが、サーバへの負担を少しでも軽くするために見直しは必要ですね。

| | コメント (0) | トラックバック (0)

日次データ用の表紙(3)

まずは売上の項目についてです。

ここでは、全売上合計と、返品と運賃を差し引いた数字を出す必要があります。
販売テーブルに、取引区分名という項目がありそこに、売上、消費税、返品、運賃とありましたので、その項目を使って集計をすればそれぞれの数字を出すことができます。
消費税については、もともと税抜金額を読み込んでいるので、考えに入れる必要はありません。
また、売上、運賃、返品には、それぞれ取引区分コードがあるようでしたが、コードでやると関数や、スクリプトを作って、後から見直すときにわ分かりづらいことがあるので、あえて取引区分名を使いました。今のバージョンのFileMakerでは、スクリプトにコメントも入れることができるのですが、コメント見なくても分かるほうが楽そうです。もっと慣れてきたらコードを駆使して作るかもしれませんが。

さてここで、エクセルのSUMIF関数的な集計が必要です。
(1)で書きましたが、具体的なやり方としては、

売上を読み込むテーブルとは別に、売上区分集計用のテーブルを作ります。
取引区分名で、リレーションをかけて

SUM(売上テーブル:金額)

とすれば、それぞれの合計が計算できます。

nitiji_uriage 表紙とは、データ処理日付で、リレーションをはっておいて、ルックアップで持ってくる予定でした。
総合計、差額、返品抜きといろいろ回りくどい項目がありますが、どの数字が実際の売上明細に出てくる数字と一致するかを確認したかったので、考えられるケースを作っておきましたが、先見の明がありました。ルックアップでは、うまくもって来ることがでなかったので、ポータルでこの売上区分集計を表紙に持っていくことになりました。

ちなみにそれぞれのフィールドの計算式は、画像のとおりです。nitiji_uriageshukei

FileMakerPro7から、ポータルの項目をバラバラに表示することができるようになりました。事前にFileMaker勉強会に出た時にその機能のことを聞いていたので、その機能を使ってみようと思いました。
総売上(表紙の売上行と売買掛の交わるところ)としては、返品行の差額列の数字を、返品(売上行と返品列の交わるところ)は、返品行の合計の数字を表示することにしました。
なんでそうなったか?それは、まだ良く分かりません・・・
(・_・)☆ヾ(^^ )なんでやねん!!

実際の明細の数字を合わせていくと、その部分の数字をもってくると辻褄があったということです。
とりあえず、急いでいたので結果オーライで先に進むことにしました。
(;^_^A アセアセ…

今のところ、問題は起きていないのでたぶん間違っていないのだと思います。
一段落付いたらゆっくり理由を解明したいと思います。
つか、こんなんばっかやな〜。まだまだやることぎょうさんありますわ・・・。

| | コメント (0) | トラックバック (0)

日次データ用の表紙(2)

次は、仕入と支払を読み込みます。
購買テーブルに、仕入と支払に関するものがあり、それを読み込むための下記のSQLを作りました。

SELECT "購買テーブル"."伝票区分", "購買テーブル"."購買NO",
"購買テーブル"."行NO", "購買テーブル"."購買日付",
"購買テーブル"."仕入先コード", "購買テーブル"."支払先コード",
"購買テーブル"."仕入先略称", "購買テーブル"."取引区分コード",
"購買テーブル"."取引区分名", "購買テーブル"."商品コード",
"購買テーブル"."商品名1", "購買テーブル"."商品名2",
"購買テーブル"."仕入数量", "購買テーブル"."仕入単価",
"購買テーブル"."仕入金額", "購買テーブル"."税抜仕入金額",
"購買テーブル"."仕入消費税額", "購買テーブル"."支払金額"
FROM "購買テーブル"

売上の時と違って、わりとすっきりとしたSQLですみました。
これでも、今となってはかなり余計なもの読み込んでいます。

"購買テーブル"."伝票区分",
"購買テーブル"."購買NO",
"購買テーブル"."行NO",
"購買テーブル"."取引区分コード",
"購買テーブル"."取引区分名"
"購買テーブル"."購買日付",
"購買テーブル"."税抜仕入金額",
"購買テーブル"."仕入消費税額",
"購買テーブル"."支払金額"

ほんまに必要なのは、上記のフィールドだけでした。
後でこの辺整理するだけ、サーバの負荷をかなり軽減できそうですね。
一段落したら、もう一度作り直してみようと思います。

さて、ここまでは比較的楽に行きました。
これからが、かなり苦労します。
何をどうリレーションをかけて、どう集計したらいいか。
どうやってレイアウト通りに、フィールドと内容を表示するようにするか。
私が休んだ時に他の操作に慣れない人のために、どうやって簡単に操作できるようにするかなどです。

| | コメント (0) | トラックバック (0)

日次データ用の表紙(1)

hyoushi

売上、仕入、入金、支払の明細は出るのですが、それを集計したものを表紙として添付しなければなりません。わりと簡単に思ったのですが、そうは簡単には終わらせてくれませんでした(^^ゞ
まずつまずいたのが、区分ごとの金額の集計です。区分というのは、「売上」「入金」「仕入」「支払」のことです。Excelで言えば、SUMIF関数のような仕組みで、ある項目の別に集計する必要があります。FileMakerでそんな関数ないので、いつもお世話になっているMLで聞いてみたら、意外と簡単に実現できるとのこと。別テーブルを作って、リレーションはって、後はSUM関数で下記のようにすればOKでだそうです。

Sum (売上日次一覧表::金額)

販売テーブルの中に、伝票区分として売上と入金を区別するフラグ(1が売上、2が入金)があることを事前に聞いていましたので、下のようなSQLで販売テーブルと、売上集計テーブルからまずデータを読み込むことにしました。

SELECT
"販売テーブル"."得意先コード","販売テーブル"."得意先略称",
"販売テーブル"."部門コード","売上集計テーブル"."部門名",
"売上集計テーブル"."売上集計NO","売上集計テーブル"."処理区分",
"販売テーブル"."商品コード","販売テーブル"."商品名1",
"販売テーブル"."商品名2","販売テーブル"."売上数量",
"販売テーブル"."売上単価","販売テーブル"."売上金額",
"販売テーブル"."入金金額","売上集計テーブル"."荷送先名1",
"売上集計テーブル"."相手先NO","販売テーブル"."販売日付",
"販売テーブル"."取引区分名","販売テーブル"."原価区分",
"販売テーブル"."伝票区分","販売テーブル"."原価金額"
FROM "販売テーブル","売上集計テーブル"
WHERE ("販売テーブル"."伝票区分" +"販売テーブル"."販売NO" = '1'+"売上集計テーブル"."売上集計NO"
OR
"販売テーブル"."伝票区分" +"販売テーブル"."販売NO" = '2'+"売上集計テーブル"."売上集計NO")
AND "販売テーブル"."販売日付" >= 20051001

今となっては、不要なフィールドを結構読み込んでますが、とりあえずありのまま記しておきます。このときは、とりあえずとっかかりになりそうな項目をすべて読み込んでいました。where区のややこしのは、販売テーブルと売上集計テーブルをリレーションして、売上集計テーブルから商品の送り先や、取引先からの発注NOなどのフィールド値を持ってくるためのものでした。自分としては、かなり高度な技を使ったつもりでしたが、今考えたらこれも不要ですね・・・でも、SQL Serverでフィールドとフィールドを連結するのには、「+」使うというのを覚えることできました♪

ほんまに必要なのは、下の項目だけでした。

"販売テーブル"."販売NO"(上にはないですが、これで代用可能でした)
"販売テーブル"."税抜入金金額"
"販売テーブル"."販売日付"
"販売テーブル"."取引区分名"
"販売テーブル"."原価区分"
"販売テーブル"."伝票区分"(ここに、売上と入金のフラグがあります)
"販売テーブル"."原価金額"

しかし、やってみないと何が必要で不要か分からないものですね。
ま、何事も無駄はないということで、自己納得しときます。(^_^)v

| | コメント (0) | トラックバック (0)