FileMaker14 スクリプト/フィールド設定/フィールドタイプ表示バグ

FileMakerPro14Advanced　　14.0.4　　フィールド設定のフィールドタイプ表示　バグ

バグといっても表示だけで、動作は正常でしたので、大して問題ではないのですが１３まではちゃんと表示されていたので、メーカーさん直そうね！って事。


んじゃ、１から説明

これはフラグとか適当なフィールドを作ってタイプを数字に設定
同じく日付フィールド、タイプは日付

次にスクリプトでデータを入力させてみたいので
フィールド設定
え！？

「必要な計算結果のタイプ」がテキストになってる？？？

んじゃ、フラグ　フィールドのほうも

え！？

またテキストになってる

んで実際のデータはどうなのか？テストすると、最初のフィールド定義で設定した
日付タイプと数値タイプになっているので、動作的には問題がないかと・・・


しかし、不安をかきたてるレベルのバグなので、
一度、僕に　ご馳走して下さい。

フィールド設定　めちゃくちゃ使うんですから・・・

軽減税率の値引き、割引、クーポン、お米券などの対応② できた！！

昨日の軽減税率の値引きで税率が混在した後の合計値引きですが
出来ました！

トイレでヒントが浮かびました。　おそるべし！


あれです。そう、

構成比

いわゆる
商品ごとの金額（単価じゃないよ）の構成比を算出し、それぞれの比率を合計値引きに当て嵌めれば公平な値引き分配ができます。ポイントカードやクーポン、なんでも応用できますね

図は、エクセルで試したものですが、これはデータベースにも該当できますね
合計の値引きを入力すれば、自動的に各明細の値引き金額が構成比によって
算出され、税込値引き、税抜値引きに当てはめればいいだけ。

軽減税率の値引き、割引、クーポン、お米券などの対応

ブログの前回、なんちゃってインボイスで、軽減税率は簡単に処理できるような事を大イバりで書きましたが、値引やクーポンなど合計金額に対して１０％の割引など、スーパーや飲食店でよくある事例に対応するのが困難であることが分かりました。

凄くごめんなさい！

POSレジを実際に作ってみたところ、明細ごとに税率や消費税を計算させることは、問題ないのですが、合計に対しての値引き、割引ができないんですね～
明細の税率が均等でないので分配ができないのです。

エクセルでたとえてみます

１、値引き、割引は今までのような合計に対して処理するのは難しい
　　500円クーポン券、合計の１０％割引など、軽減税率対象の明細があると

　　今までのように合計から値引きが出来ない
    

2、 500円を引く場合、明細数５で割ったとしても、単価が100円に満たないケースもある


3、単純に税込4,199円から500円を引いて3,699円としても、その内税が計算できない

なので、明細ごとに値引・割引処理をしないと軽減税率には対応できない。
百貨店などはポイントや顧客ランク（外商さん）など特典が違ったりするけど
合計金額に対しての処理が難しくなるわけ。

そうなるとさ、レシートは1項目2行表示しないと
商品名、フラグ、単価、個数、税率、消費税、金額、値引・割引は表示できないでしょう。


たとえば明細ごとに割引したとして、
そこには優先順位が無いので、気分や任意、お客様の合意で
消費税の高い１０％の明細から割引するのではないか、そんな安易な方法では
軽減税率の意味をなさないのではないか、、などなど
軽減税率対象商品と、それ以外を分けて会計する方法もあるけど、
お客様を待たせ、実務的に難しいのではないかと予想できる。
海外ではどうなのか分からないけど、既に商品ごとに幾らOFFと
値札が付いている事が多く、合計に対しての値引きは、見ていない。

日本ではお米券など他の商品と交換できるものもあるが、扱いが変わると思われる





この問題、解決したので、こっちも見てね！

• 								9

FileMaker でデータベースを作る

僕的には、データベースは自由に作っていいと思います。
けっこうマジで言ってます。

デベロッパの方はそれじゃ困りますが、一般のユーザーなら自由でいいと思います。
たぶん、満足のいくものでなくても最後まで作り上げて、動かしてみたら
感動するんじゃないかなぁ・・・

最後まで作り上げたら、処理をもう少し早く出来ないかとか、誤入力を防ぎたいとか
もっと実用的な検索にしたいとか要求が起こるわけで、始めっから完璧な設計で
開発しようなんて、逆に面白くない

スクリプトにしても長くたっていいじゃないですか、
他のテーブル、レコードやフィールドに影響を与えなければいいんです。
邪道でもちゃんと動けば邪道ではなくなる。
計算式だって、関数が分からなければ、フィールド増やして足し算、引き算、掛け算、割り算すれば大抵の事はできます。　いいんですよ、最初なんだから・・

昔の話なんて良くないのですが、変数もなければグローバルフィールドもなく、ポータルもリレーションも無い時、なぜか関連レコード移動とルックアップはあって、正規化は出来ないにしても見積もりや売上・請求システムなど凝った皆さんは難なく作られてました。凄いですよね・・・
商品マスタのウィンドウからコピー、貼り付けですが（笑）　
エクセルもワードもアクセスも売ってない時代（ジビ・カルク、マルチプランはあったかな・・・）に、僕はクラリスFileMakerProⅡの「プレビュー」という聞いたことの無かった機能にあこがれて購入したんです。分厚いマニュアル付の青いフロッピー４枚だったかな・・・

プレビューなんて単語それまで聞いたことありませんでしたから・・・
たぶんね、他にプレビューって機能付いたソフトは無かったと思います（未確認）
当時、農協の指定伝票、これで作れるぞ！って開発部がこぞって導入しましたから

バックもフロントも気にせずにデータベースが開発できるなんて、なんて凄いんだろうと、たぶん今のバージョンアップより感動したと思います。
（当時4th DimensionというMac用のデータベースソフトもありました）

誰が作ってもそれなりに動くのがFileMakerですし、まぁ、それも少し問題もあるのですが
必ず次の対策があるわけなので、修正した方が良ければ修正すればいいだけです。

正しいか誤りかより、とにかく作り上げてみることって大事だと思いますねー。
世界でたった一つのデータベースができるわけですから

面白くなるための始まりは否定より自分を肯定したほうがいいのではないかと感じたわけです。
Macが自由な発想のユーザビリティを重視し続けるっていいですよ。

FileMakerPro14のスクリプト・ワークスペースが ちょっと・・・

環境　Win8.1 　FileMakerPro Advanced 14.0.2

CPU  i5  4460 メモリ16G

＜スクリプトワークスペース＞

・スクリプトの位置を変更するときドラッグの反応が悪い
　１３とは比較にならないほど反応が悪い　（Macはどうなのかな？）
・置いていかれる（ラグのような感じ）

・左のスクリプト一覧から選んで名称変更しても、タブに表示されるスクリプトに連動されていない
スクリプト名はタブ上で変更しなければいけないのか

・前回スクリプトを10個作って、一度閉じて、再び開くと、なぜか前回作ったスクリプトがタブに複数現れる。とても親切心とは思えないのでせめて任意設定で表示させないことを希望

確定とか作ってみる

そんで、新規でスクリプトを追加してみる

左のスクリプト一覧から名前を変更しても保存されず、上のタブ名称も変わらない

気を取り直してファイルを閉じ、再び開き、スクリプトを開くと、さっき作ったスクリプトがタブ上に全部ならんでいる・・・

しかも最初に作ったスクリプトがアクティブになっている

たぶん、「気を付けるように・・」もしくは慣れたら、、という問題ではないかと思う。

タブ上でしか、スクリプト名称を設定できないのに、過去に作成したスクリプトを全部並べていたのでは、当然ながらミスを誘発してしまう作りになっているとしか思えない。

うちの場合は、まだ１３で開発して、１４で新機能追加といった感じかな

１４の新機能としては良いよ。

シリアルNOの初期値化と欠番

いろんな局面でシリアルコードが使われていますが
特に入力と明細など親子関係を持つ伝票NOや、病院などの外来で日によって詳細が増えるもの、弁護士さんなら案件Noなどが対象かと思うのですが、コード番号をKeyにしてデータベースを処理される事が多いかと思います。
（顧客マスタや商品マスタなど、日々増えるものでなければデフォルトのオプションで十分）


レコードを増やせば001+１（増分）

はオプションで設定できますが、翌日は001から始めたい
などの場合は自己リレーションと計算式を用いれば可能になります。

これは日付で初期化し、001から始める方法ですが、月によって001にしたり桁を増やして0001にしたりも出来ます。コード番号が整理されて帳票なんかも見やすくなります。

サンプルがダウンロードできますので見ていただければ分かるのですが、

シリアルコードを作るのに、それに関係するフィールドが増えちゃうのが難点でもありますが、覚えて損はないかと思います。デフォルト装備のオプション設定では、001に戻すために都度、管理者権限のデータベースの管理でオプションを変更する、なんて面倒な事したくないですし・・・。

日や月によって001に戻ってくれたり、レコードを全部削除しても、新規レコードで001から始まってくれるのは便利です。

＜欠番＞

しかし、このコード、親子関係にあればKey設定をしますので、レコードを削除した時に欠番をどうするか考えなくてはいけません。

今回は欠番が発生したらそのままにする方法と欠番以降を詰めて連番にさせてしまう方法の2種類をサンプルにしました。

いろんなサイトでシリアルについての注釈が掲載されていますが、僕的には欠番を詰めて連番にさせる方法は好ましくないと考えています。

リレーションで親子関係にあれば、欠番が詰まって連番化されたことで、子の側のデータもズレて（書き換わる）しまうからです。これでは整合性が保てません。ですので、レコードを削除して欠番が発生したときは、そのまま放置をお奨めします。

では、欠番なしとは、どういうケースで使用するか、ですが
伝票などのトランザクション（親子関係）ではなく、呼び出しだけに使用するマスタ等であれば、Noを詰めても良いと考えます。ただし、商品マスタなど後に商品別の分析をするのであれば、危険です。担当者や人事などでも定年や退職などで欠番が出ますが、欠番なしになると欠番以降の関連データが飛んでしまいます。

僕の場合は、欠番なしという手法で開発を手掛けたことはありません。





ダウンロード（FM13以上）

マウスホイールでレコードが変わる（画面が変わる）

マウスホイールでレコードが変わる（画面が変わる）
これは、

スクリプトの

ツールバーの表示切替[ロック：隠す]

で動かなくなります。


ロック解除のスクリプトと併用させると、けっこう使えます。
明細の入力時など、マウスホイールは危険ですね～

値一覧をポータルにして絞り込む （中分類、小分類）

前回のファイルを利用して
値一覧をポータルで表示させて
絞り込んでいくもの。


値一覧のドロップダウン表示がどうも好きでない方向けです。
ダウンロードできますので中身をみてください。
苦肉ですが、画面はすっきりｗ




中分類を選択すると小分類に

小分類を選択すると商品マスタに

商品マスタを選択すると元の中分類に

前回のファイルに中分類のＴＯ「中分類フロントＰ」を追加してポータルにしました。

１３ならではのオブジェクトを重ねて、スクリプトのフィールド設定で隠してます。




ダウンロード（ＦＭ１３以上）

ＦｉｌｅＭａｋｅｒで分類 絞り込み（中分類、小分類）

ひさびさにＦｉｌｅＭａｋｅｒ

あれから時は過ぎ、なんと１４なんかも出ちゃったりしました。ユーザーが増えました！ということでしょうね。ユーザーが増えるという事はいいことで、バージョンが上がったり、メーカー側の対応もよくなったりします。


随分と前に弁護士向けのソフトで大分類、中分類、小分類について書きましたが
そんなに分類分けが必要でなければ中分類、小分類だけでやってみようということです。

今回はバージョン１３で作ってみました。
ダウンロードもできますので試してみてください。

動的値一覧と何が違うのかというと、ちゃんとid,と名称フィールドを作り、しっかりマスタ管理して動かそうということです。
よくあるのは、名称を値一覧にすることですが、当然索引設定されますので非常に検索呼出しが早くなるのですが、名称変更があり得るのなら、しっかりidなどの番号をＫｅｙにして管理されたほうがいいと思います。


＜２つの用途をみたします＞

　事前登録時の分類絞り込み（マスタ側）

　事前登録されたデータを分類によって絞り込み、ガイドに表示（入力画面など）


というわけなので、事前登録時の考え方、
それを呼び出す絞り込みの考え方、そしてそのリレーションの組み方は当然違います。

事前登録の画面（商品マスタ）

先に中分類マスタ、小分類マスタを設定し商品マスタ設定時には、分類を絞り込り込める設定です。（中分類マスタで小分類を設定する）

一方で、入力画面で商品を分類の絞り込みによってガイド表示させる場合は、中分類をＫｅｙにした商品マスタのテーブルオカレンスから値一覧設定で絞り込む様にします。

中分類側の値一覧設定、中分類マスタではなく、中分類をＫｅｙにした商品マスタから閲覧するように設定します。

小分類は、中分類をＫｅｙにした商品マスタからidを絞り込ませます。
名称は小分類マスタのテーブルオカレンス側から拾いましょう。

メインテーブルを関連レコード表示させると、小分類をＫｅｙにした商品マスタのポータルにデータが表示されるという仕組みです。

いろいろ使えますので改造してみてください。


ダウンロード（ＦＭ13以上）

Admin Console その２

Internet Explorer 11 では、FileMaker Server 12 の Admin Console を起動できない

FileMaker Server 12 の Admin Console がサポートしているのは、次の Web ブラウザだけだという点にご注意ください。

Windows:

• Internet Explorer 8, Internet Explorer 9
• Firefox 4.x
• Safari 5.x

Mac OS X

• Safari 5.x
• Firefox 4.x

つーか、Windows8.1は、Internet Explorer11以外は使えないので、FMS１２は使用出来ないということですねー。Windows7に落とせって？

説明：
FileMaker, Inc. は、上記の FileMaker 製品に関して、この問題を認識しています。

ですって。

セミナーとかワークグループとかやるんなら、余計な経費使わせずに、ちゃんとこういう仕事しとけよ、と思うねー。サーバーマシーン新しいものに交換した人どーすんだよ。

ひさびさにAdmin Consoleと戦うことになったの巻

サーバークラッシュ、リカバリそしてFMS12のインスコ
HDも古いし、ばいおす壊れちゃ、しゃーないよね。
なんだか、いろいろいじってたのがよくなかったらしい。
中身を、ちと交換して設定しなおしだよぅ


ひさびさにAdmin Consoleと戦うことになったの巻ー！

FMS１２なので、まだJavaとも戦わなくてはいけないと覚悟していたのですが、月日が経てば、Internet Explorer のバージョンも変われば、Javaも変わる。

サーバー以外には、ブラウザは普通チョロメ使うでしょ？チョロメ。
チロメともいうか・・・

さらさらのPC（ボロですが）であっても、そりゃめんどくさいわけで・・・

とりあえず、FMSインスコ前にIIS7確認
火壁でポート空き確認、なきゃ、開けまくる
とりあえず、5003、50003、16000、16001、16004、16006、開けすぎでしょ。

何も知らず、FMSインスコ。Javaの責任にするような文言がズラズラ・・・
７がダメなのでアップしろとのこと。本当なのか・・・
こういうの見てるとダイアログの文章、もうちょっと親切にしなきゃいけないと自分も反省。

なんだ、java8かと思い、中身見たら、セキュリティレベル高過ぎ。
ありえないのでアンインスコ
ついでにフォルダごとゴミ箱に入れる


Java７再び入れ、Javaキャッシュ消し消し、Internet Explorerのキャッシュも消す（これ、履歴ね）


え！
まだ、Javaどうのこうの言ってるー。

ORACLEという文字が笑ってる気がした。

なんだよ、さらのPCなのに・・・
Internet Explorerのあくてぃぶえっくす見てみる・・・とくに問題なし



あ、あ、
Internet Explorer１１になってるよ。
たぶん、これは使うことないでしょ。
コントロールパネルのソフト消すところの
「ウィンドウズ機能の有効化または無効化」で１１のチェック外してOK押して
「インストールされた更新プログラムを表示」を押すと
まだ１１がのこってるので、アンインスコ。
これで、ロールバックになるんよ。
（最初に若いバージョン入れてなくても）

再起動したら、９になってた！
おい、１０じゃないのかよ！？


ふたたびAdmin Consoleを起動

また、セキュリティがどうのこうの言ってるので
Javaのセキュリティレベルを“中”に設定。
Java８にするとさ、“中”がないのよ。

強引のようだけど、そういう意味でしょ！？

ホレ、立ち上がった。

なんともめんどくさいわけで・・・。
リカバリ後のFMS入れる前に、ウィンドズアップデートしちゃったから
まさか、Internet Explorer１１が原因とは思わなかったし・・・

１３からは、良くなった？

ODBCも使えちゃったりするんだよね・・・・

FileMaker トランザクション

FileMakerはiPadやiPhoneなどの端末を利用できるGoが出来てから、今まで敬遠されてきた方も、新たに採用されたり若干戻ってきたりしているらしいです。
そうすると、口々にトランザクション制御についての質問をされているのですが、たぶん、OracleやMySQLを使用されてきた方々は、当然の疑問かと思います。


正直な話、FileMakerの性質上、トランザクション制御を求めるのは僕個人的には違うのかなという気がしています。

FileMakerの開発が早い理由のひとつとして、データの確定さえしていれば、おおよそ既に内部で一貫性にて処理されており、SQLでいう、ロストアップデートやノンリピータブルリード、ファントムリードが発生しない作りになっていることです。（ダーティリードはロールバックしても間違ったままのデータ状態で、FMの場合は別途ロールバックを仕掛けないとそもそも起こらない）
ACID特性でたとえると、Consistencyに相当するのでは・・・と思います。



＜トランザクション＞

トランザクションとトランザクション制御とは意味が違います。

トランザクションとは、たとえば、入庫テーブルの入庫数が更新されれば、在庫テーブルの数量が変わる。売上明細に商品と数量を追加すれば、売上の合計が変わるなど、お互いの関係・依存する一体の処理をいいます。　担当マスタや商品マスタなどとは扱いが違うものです。
始めての方は、販売管理や入庫管理などの入力される明細などの箇所、と思っていただいて良いのかと思います。FileMakerはデータが確定されれば、一貫してテーブル間でデータが連動されて更新されます。



すなわち、SQLのような隔離性水準（更新処理）を指定する下記の



SET　TRANSACTION

　　ISOLATION　LEVEL

　　　　　Read Uncommitted　または

　　　　　Read Committed または

　 　　　Repeatable Read　または

　　 　　Seriaｌizable



の様な設定は、まったく必要ないということです。



＜トランザクション制御＞

トランザクション制御とは、トランザクションデータを確定（コミット）させたり、なにか問題が発生したときは取り消す（ロールバック）処理の事をいい、排他処理ともいいます。

FileMakerの場合、デフォルトではフィールドの外をクリックしただけでデータが確定（保管）されます。（いいか悪いかは別として・・・）ロールバックはスクリプトなどを仕掛けない限り、元には戻りません。この単純明快さを開発に利用しない手はないと思うのです。
ですが、その単純明快な機能をわざわざ殺し、データを一旦グローバル変数に格納させ、更新させるまではなにもさせず、読み込んだデータが、他のトランザクションによって更新されたかをチェックさせて、ロールバック、コミットさせるSQL手法（楽観法）を用いていたのでは、いったい何のためのFileMakerなのか、そもそも何がしたいのか論に戻ってしまいます。


FileMakerで開発する場合、ユーザーの日常業務、伝票発行等単位ではなく、せいぜい、まとめて行う請求処理中に横入りしてもらいたくない程度のロックくらいか、まとめてデータの置換えが発生するときの制御であれば、ポータルを使って関連レコードをまとめてロックすればいいだけで、毎日の伝票発行毎にロールバックさせるため、わざわざグローバル変数に格納させるスクリプトを作る意味があるのか非常に疑問です。そもそも伝票毎では同レコードを開く事が出来ない作りになっていますからロックを気にすることもありませんし、確定しているんだから、ロールバックじゃなくて書き直せばいい話です。明細１０行確定させず、宙に浮かせ、１０行ロールバックされるほうが迷惑な話という事にもなりかねません。

出来なくはないけれど、FileMakerの性能を下げさせ、めんどくさい非効率開発だと考えます。

これを奨めないFileMakerはRDBMSじゃないとまで云う方もいますが、僕は画期的なRDBMSだと思っています。というより、SQLとは性質が違うと考えるべきかと思います。


障害が発生したときに、更新ログを使って障害発生時までロールバックさせるのではなく、バックアップなどでのロールフォワードを推奨させる考え方、という根本的な考え方の違いもあります。

なんだ、大規模向きじゃないんだ、ではなく、そもそも性質が異なります。

SQLとFileMakerを上手に連携させる事によって明るい希望を持たれるデベロッパーもいます。

いずれにしても開発者事情ばかりではなく、使用者にとって楽で安心、使いやすいものであればいいのだと思います。

PCに埃

最近、なぜかパソコンの起動トラブルが続いて
２年半前に購入した　Intel Core i7のマシーンが早くもダウン、

と思ったら

埃でファンが回らなかったという恥ずかしいトラブルでした。

最近はスマホやタブレットばかりでPCのメンテナンスなどほとんど

していませんでした。

PCの中を開ける回数も減っていたので、開けてびっくり！

埃というか、フエルト生地、もしくはレゲエ状態で

ファンも基盤も外し、丁寧にお掃除。

無事、PCも元気よく起動。

たぶん、かまってくれと、怒ったんだと思いました。

FileMakerで相関分析

普通、相関分析というと、点がごちゃごちゃ分散しているものですが、ちょっと強引にクロス集計ではなく、通常業務で使う累計で相関分析を作ってみました。

なんといっても、集計を使った累計の更に集計を出さなければいけなかったり、集計後に更に平均値といったちょっと邪道な手法も使いました。

紹介数と契約数の相関係数を求めるというものですが、さすがに相関分析はエクセルと違ってめんどくさいです。でも絶対に出来ない！というわけではないので・・・

共分散÷（紹介の標準偏差×契約の標準偏差）＝相関係数

が最終ゴールです。

万が一駄目なら掛け算、割り算で母集団分散値や標準分散値を出そうと思ったのですが、２乗の集計に対して、更に掛け算、割り算が必要になり、そっちの方が別途テーブルを作るなどしてめんどくさいので、素直にStDev関数を使いました。

しかし、この関数、繰り返しフィールドか関連レコード側から計算させなきゃ、そのままでは「？」になるので、こういった表の場合は、さすがに自己リレーションをしてわざわざ関連レコードから計算させなくてはいけません。


入力箇所は紹介数と契約数だけで、どこかに５００とかありえない数字を打ちこむと、相関関係はありませんの数値が出るわけです。

クロスではなく、累計で計算しているので、違和感があるかもしれませんが、こんな方法もありますということで。



ダウンロード（１２以上）

FileMaker データベース問題解決ガイド Good

やっとですが、FileMakerPro13Advancedをとりあえず１ライセンス分購入したので、
（遅いだろ）
と、申しますか、１３の事、何も知らない私でして・・・
凄いですね、１３！


そのうち、会社のサーバーやクライアント達も・・・

ってことで、さっそく木下先生の本を買ってみました。
にこたまで。

★★★★★

キープランニングの木下社長の本って、他とぜんぜん違うんですよね～
毎回購入して良かったって思うんだなぁ。
特に今回のは星５つです。ちゃんと読める本なんです。

にこたまの駅前で買って、スタバに入って１時間半くらい熟読。気づいたら成人式のお嬢達が賑わいだして、すぐ近くの高島屋のスタバで再び熟読。僕は、スタバでは本読めない人なんだけど、今回のは、やはり１３の機能説明ばかりではなく、実践でのデータベース設計に重きを置いているところや、ユーザビリティの向上、高速化テクニックなど興味あることばかりで、とても良い本だと思いました。（サンプルもダウンロードできます）

FileMakerって誰がDB作っても動いちゃうじゃないですか、そこが利点でもあり、何年もどこかに負荷をかけながら動かしてしまうという欠点もあったりするわけで、ですから、正規化や索引の持たせ方、設計の仕方から見直すという機会を与えてくれる本なんじゃないかなぁ。

僕の様な古い人間ほど、昔のまま引きずったりするので「こんなに素晴らしい手法があるんだ！」と感動させられるわけです。

たぶん、著者は優しい人なんだと思う。



FM主催のセミナーやイベントとか忙しくて行けない人とかってけっこう居ると思うんだよね。
認定すら受けられない地方の人とか・・僕もそうでした。

FileMakerの書籍って少ないし、PDFとかネットのQ&Aで事足りるわけでもないので、今回の書籍は僕的には凄く評価は高いです。

FileMakerで損益分岐点 グラフ

さてさて、今回は集計使ったり、グラフなんぞ作ってみましょう。

損益分岐点です。
たぶん、エクセルなんかでは作ったことあるのかと思いますが、FileMakerで作ると
日々の売上データや、仕入（原材料＝変動費）、一般管理などのデータから、集計をかけて
より簡単に分析できるというサンプルです。ちょー楽勝です。

FileMakerはこういうの苦手と思ってる方、それはまったくの誤解です。
せっかく、基幹システムなど開発したのなら、あとはガンガン分析資料を作っちゃえばいいんです。
わざわざ、エクセルで毎回ブックシート作る必要もなくなるでしょう。

特に、なにも工夫はありません。
累計出して、グラフにして、損益計算させるだけ。

あとは、カスタマイズして、日付範囲指定させて反映さえるとか、月別に絞り込むとか
大して、難しいものではありません。

固定費とかは、一般管理費など勘定科目の他に固定費という区分を作って、集計させればいいだけ。
（今回はめんどくさくてやってないですが・・・）
固定費は最終合計金額を始めから、最後までズラーーーっと並べれば完成。
（並べなきゃ、まっすぐの線にならないし）
変動費だって、日々の仕入れを変動費の分類で集計させればいいし・・・。

累計の出し方は、売上フィールドの「現在の」集計指定すればいいです。


ダウンロード（１２以上）

FileMaker ExplodeToMultikey ( string ) 関数

ExplodeToMultikey ( string )

このカスタム関数はどこにも掲載されないくらい、日本ではあまり使われていませんが、使い方によっては、たぶん使える関数です。
最近バージョンが変わっても関数の事ぜんぜん気にかけていなかったので、デフォルトで持っているのものと思ったら、カスタム関数でした。だめですねー僕は。

フィールドが「名前」であれば、ExplodeToMultikey ( string )を使って名前の先頭文字を計算式によってインデックスKeyにしてしまおうというもの。それを上手に使っているのが、こちらのサイト

別ウィンドウを表示させることが流行らない日本では違和感のある作りですが・・・

１バイトのアルファベット文字を入力するとリスト上（ポータル）で、文字数によってストレスなく絞り込まれて表示するというもの。２バイト日本語の場合は、Enterキーを押さなければ絞り込まれないというストレスがありますねー。

ちょっと、カスタマイズ

この中にアルファベットを入れてみる。

↑外人さんが多そうな「J」を入れてみた。

↑次にエンターキーを押さずに「e」を入れると、ストレスなくポータル内で絞り込まれる。

↑　次は日本語。「ま」を入れてみた。

やはり、エンターキーを押さないと表示されない。

↑次に「い」を入力して、エンターキー。

アルファベットは、エンターキーを押さなくても絞り込まれるだけに、日本語入力後のエンターキーは、やはりストレスを感じるねー。

そういうこともあって、日本人名を入れてフィールドを追加したんですが、普段からローマ字入力をしているので、それをそのまま検索に活かせばいいじゃないか！と思い、ストレスの無い絞り込み検索を実現させました。

↑データ入力が大変なので、デモ用に若干入力したAの段「ai」と入れてみました。

まったくストレスなく絞り込まれます。

↑　次に「k」を追加。　上手く絞り込まれました。

エンターキーを押すというのは、どうしても改行のミスを誘発させてしまうので、得意先マスタなどは、かな検索もいいのですが、ローマ字検索を有効に使えば、なんだか、データベースを使ってる気になれるかもしれません。

品番検索とか郵便番号検索とかにもいいかもですね

ダウンロード

（FileMakerPro12以上が必要です）

カレンダー

初心者のFileMakerQ&Aで、いつもHiroさんが親切心満点で公開してくれるカレンダーを少しカスタム。

前にも作りましたが、担当者id入れていなかったので追加。
Google　APIの提供されていた祝日が変更されていたため、外部供給に影響されない仕様のものです。もうちょっと作り込めばもっといいのが出来るのですが、時間入力ですとか、進捗状況とか入力するのが嫌いなので、簡単でずーーっと使っていけるものがいいということで再度UP

Nav（ナビ）レイアウトも、使って行くうちに楽だということが判明したので、それもそのまま


後々、受注日とか、照合させてカレンダーに自動で表示させることも出来たりします。
弁護士さんシステムなんかでは期日とかも日付で照合させればカレンダーに表示させられるので、カスタマイズするには、ごちゃごちゃ無いこういうのが楽かと・・・


それと、いちを弁護士さんのシステムは、前回で一旦終了。
iPadを使用して、現場画像を取り込むなどの機能的なものは今後も随時紹介していきます。

過去ログでいろいろとダウンロードしてカスタマイズしていくと、たぶん作れちゃったりします。

製品版は、製品版で作りますが、サーバーがある事を前提に、トランザクションやアクセス権、バックアップなど、DB管理者用のメニューを増やしたり、請求についても分割請求などができるものや、さすがに前回の様な足し算、引き算だけで請求というわけにもいきませんので、ボリュームは相当増えて行くと思います。
FileMakerPro13で作ります。

いろいろと試してはみましたが、やはりデータをワードやエクセルに渡さないと、見出しやぶら下げ、ピッチや余白などFileMakerでは公文章としての文章編集機能が充実されていないため、3回でご案内したなでしこプラグインは必要かなと思いました。

ただ、LANになるとたぶんODBCを使用となるでしょうから、その辺は時間をかけて作りたいと思っています。
FileMaker自体も計算機能や関数など充実していますから、財産目録なんかも作れてしまいますので、別Fileで作り込んでリレーションという選択肢やエクスポート、インポートが使いこなせれば、
FilleMakerの事件管理の関連Fileの中にテキスト、ワード、エクセル、PDF、と同じようにFileMaker自体のFileを置くという方法も、ぜんぜん有りです。FileMakerのFileって軽いですから・・


それと、前回集計を使ったら処理スピードが遅くなると申しましたが、無駄にテーブルオカレンスを増やしても処理スピードは遅くなります。ただ、前回の場合は、一得意先の締分をめくるだけですので、各ポータル内にそれぞれ1000レコード存在するとは考えにくいので、前回、今回、次回、それぞれ３０発生していたと想定して比べると、やはり圧倒的にテーブルオカレンスで作り込んだ方が早かったです。また、前々回締のポータルは、発生した分のレコードが累積されてたまるようになっていますので、ポータルフィルタで、何カ月、何年まで溜めるか、グローバルフィールドを使用して選択できるようにするといいかもしれません。
レイアウト上で前回、今回、次回などポータルの比較が必要無い場合は、論理関数やLet関数、変数を使って締日を絞り、必要なものだけ閲覧できるようにすればいいかもしれません。

レイアウト自体が重くなっちゃ困りますしね。




ダウンロード

（FileMakerPro１２以上）

第25回 自分で作ろう！ 弁護士向けソフト 請求確認と消込入金、ダイレクト入金

FileMakerで請求・消込入金・ダイレクト入金

あけましておめでとうございます。
引越しやら、出向やらで、手をつけられずにいました。
すみませんでした。

暮れから、年明けにかけて作りこみました。


今回は請求と入金についてですが、入金処理には売上伝票単位で入金処理を行う「消し込み入金」と、普通に入金処理を行う「ダイレクト入金」の２通りがあります。

どちらかひとつという販売管理ソフトも多いのですが、どうせなら一緒にふたつやってしまいましょう！ということです。いいねぇ～

弁護士さん向けというより、通常の販売管理ソフト上の一部として考えて頂ければと思います。
前回同様、デザインは重視していませんので、クラシックなFM１１で作っています。


残念ながら、時間もなかったので請求書発行までは作っていませんが、請求・入金確認画面までは作りました。後は、請求書発行用のテーブルを作り、データを渡して処理するだけなので簡単です。（売上日や入金日を今回の締日に絞って、過去に作った見積もりから売上にデータ移行する要領で飛ばせば良いだけです）


これが通常と違うのは、請求・入金の確認と追跡をしたい、ということです。
通常、集計を使うと、確認するどころのスピードではなくなりますので、集計を使わないという条件で作り上げました。（なので、リレーション図がクモの巣状態に・・）

リレーション図をみると非常に複雑に見えますが、ごくごく単純に作り上げています。
得意先に設定していた締日をふんだんに利用して、テーブルオカレンスを地獄なくらい作り、
変数も関数もスクリプトも特に使わず、リレーションの照合と足し算と引き算で作りました。
せいぜい、sum関数（笑）


また、なんでもかんでも照合によって自動連鎖させるのではなく、コンテキストなどのデータの流れ、自動連鎖と連鎖を止めるという考え方も必要です。何処で繋げて、何処で断ち切ってるのかを考えながら作るには、とても良い課題でした。

どれが、最初に作ったテーブルで、どれがテーブルオカレンスなのか印を付けていませんので混乱するかもしれませんが、これだけは作りこまないと分からないかもしれません。


請求、入金システムの考え方、作り方は、人によって違いますし、考え方も違います。
単純に売上伝票を日付で絞り込んで請求とする考え方、売上決定後に分割払いの要求や延滞利息などを考え、別に請求書としてインポート・エクスポートさせる考え方

印刷してから確認するのか、処理する前に確認・追跡できるようにするのか、数か月前にさかのぼった売上伝票はどう処理するのか、入金忘れの後処理、ダイレクトな入金処理、伝票単位での消し込み処理、POSレジとの連携で現金売上も頻繁に発生する中での売掛・請求処理、更新作業の考え方など、本当に様々です。

今回は、こうすべきだ、という概念を持たせずに、後々拡張しやすい仕様で作ろう！という考え方で作っています。

これは、消込入金の画面です。
伝票単位で入金処理を行う方法で、業種・業態によっては、ダイレクトな入金処理より、こちらを使用するケースもあります。まとめて請求、まとめて入金ではない場合、営業さんが現地で、この伝票分を現金で集金されたり、レジの売掛と連動された場合などは、伝票単位で消込入金を行います。この場合、売上日は１１月締前で、１１月の締後に訪問したとき、たまたま現金で一部の集金ができたというような、過不足がある場合、通常、残りは、まとめてダイレクト入金で処理をします。
どうしても、過不足分も消し込みで処理をする場合は、売掛の後ろに入金日と未入金分というフィールドを置いて処理をすると良いかもしれません。（入金明細までカスタマイズする必要が出てきます）

ポータルの上に

前回請求
前回入金
前回繰越
今回売上
今回入金
今回請求
とあります。

消し込み入金時と、ダイレクト入金、合算された今回請求分が閲覧できます。

リレーションによって、前々回から締日を分けてポータル表示させたもの
確認、追跡される場合、更新作業に関係なく閲覧でき、過去の売上に対して、いつ入金されたか、今回の入金が予定と違う場合、得意先へ電話での問い合わせなど、非常に便利です。
集計を使っていないので、さくさく動きます。

ダイレクト入金画面
伝票単位を気にせず、得意先誰、入金日、ドカーン！と入金という処理です。
細かいところは、画面に注釈を入れています。

FMを使用しない人が嫌になっちゃうリレーション図
でも、僕的には、IBM標準のER図より、こっちのほうが分かりやすかったりします。

どうして、こんなクモの巣状態なのかと申しますと、前々回締日、前回締日、今回、次回というふうに、売上も消込入金もダイレクト入金も、それぞれを分けているからです。
それぞれ、Sum関数で合計を出し、引き算すれば、各締の合計が取れます。
（表示は、単純な範囲指定のポータルフィルタを使用）
このリレーションを使わず、集計やスクリプトを使用して分けると、処理スピードが遅くなり確認どころではなくなるため、このような一見複雑なものにしました。


いわゆる、現場では請求書を発行する前に、売上と入金状況を確認する作業が発生するのですが、印刷された帳票上ではなく、システム上で確認・追跡できるものを作りたかったわけです。


請求は、締単位なので、前回、今回という表示
売掛は、月単位なので、前月、今月という表示です。（売掛は作っていません）
要領は同じですが、売掛残高一覧表は、得意先の締日に関係せずに月締めですので
それこそ、集計とスクリプトを使用してズドンと印刷でよいのではないかと思うのであります。



今回のダウンロード

FileMakerPro１１以上が必要です。
１２、１３は変換してご利用ください。