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１１以上が必要です。
１２、１３は変換してご利用ください。