2013-01-29

簡単? FileMakerで在庫管理(4) ―― ExecuteSQLによる在庫数算出

 これまで FileMaker Pro による在庫算出の基本、繰越処理の考え方、複数倉庫の在庫算出方法についてご紹介してきましたが、今回は商品在庫を求める方法として、3 つのパターンをご紹介したいと思います。

在庫算出の 3 つのパターン

パターン1: FileMaker Pro で在庫算出専用の TOG を構成する方法


 弊社で配布しているシンプルな入出庫・在庫管理システム/テンプレート 「FMEasy 在庫」では、以下のようなリレーションシップを構成することによって、特定時点の商品在庫を算出しています。

ここでは |×| 以外のリレーションは無視して下さい。

※「簡単? FileMakerで在庫管理(1) ―― 在庫算出の基本」に類似リレーションの解説がありますので、参考にしてみてください。

 ユーザが商品レイアウト上の [g在庫基準日1]に任意の日付を指定すると、在庫算出開始点となる日付[g在庫基準日2]を決定します。
 [g在庫基準日2]~[g在庫基準日1]の範囲内の日付で発生した商品の[入庫数]と[出庫数]が対象となるようにリレーションシップを組み、対象となった[入庫数]、[出庫数]、および商品側の[繰越在庫数]を使って[g在庫基準日1]の在庫を求めます。

 このように考えた場合、商品テーブルの [c在庫数]の計算式は、たとえば次のようになります。

Case(IsEmpty(繰越情報::繰越日付) or g在庫基準日1 < 繰越情報::繰越日付; 導入時在庫数;繰越在庫数) - Sum(入出明細_商品::出庫数量) + Sum(入出明細_商品::入庫数量)

 この計算式は比較的単純ですが、リレーションが不細工なことと、[g在庫基準日1]や[g在庫基準日2]という管理フィールドを商品テーブルに持たせざるを得ない点には、スマートさがあまり感じられませんね。


パターン2:ExecuteSQL関数を使用する方法(JOINなし)


 FileMaker Pro 12 に新たに追加された ExecuteSQL 関数を使うことによって、商品の在庫を算出します。

 この方法を採用すると、入出庫数絞り込みのためのリレーションシップが不要となります。
 また、商品テーブルの[g在庫基準日1]フィールドおよび [g在庫基準日2]フィールドも不要となります。
 ユーザが日付を指定する[g在庫基準日1]は、ユーザインタフェース専用テーブル UI に移動してしまいましょう。



 上記のように、 入出明細TO さえあればリレーションは不要となります。単純なのがいいですね!
 それでは、商品テーブルの方に在庫算出用計算フィールド[cNoJoin在庫数]を追加し、計算式を以下のようにしてみましょう。


//$date は期間開始日、$date~ UI::g在庫基準日1 の入出庫の計を加減して在庫数を算出
Let ( 
    $date = 
      Case(
        IsEmpty(繰越情報::繰越日付) or UI::g在庫基準日1 < 繰越情報::繰越日付; Date( 1; 1; 1 );
        繰越情報::繰越日付 = UI::g在庫基準日1; 繰越情報::繰越日付 +1;
        繰越情報::繰越日付 +1
      );

    Case( IsEmpty( 繰越情報::繰越日付 )  or  UI::g在庫基準日1 < 繰越情報::繰越日付; 商品::導入時在庫数;商品::繰越在庫数 )
  - ExecuteSQL ( "SELECT SUM( \"出庫数量\" ) FROM \"入出明細\" WHERE \"商品ID\" ="  &  商品::商品ID & " AND (\ "入出庫日\" BETWEEN '" &
   GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "') "; ""; "")
  + ExecuteSQL ( "SELECT SUM( \"入庫数量\" ) FROM \"入出明細\" WHERE \"商品ID\" ="  &  商品::商品ID & " AND ( \"入出庫日\" BETWEEN '" &
   GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "') "; ""; "")

)

 ここでは $date が [g在庫基準日2]フィールドに代わって期間開始日となるため、 [g在庫基準日2]フィールドは不要となります。


パターン3:ExecuteSQL関数でJOINする方法


 最後は、ExecuteSQL に結合(LEFT JOIN)を組み込み在庫を算出する方法です。ここでは出庫テーブルと入庫テーブルを入出明細テーブルに JOINし、出庫.出庫日 と 入庫.入庫日 を WHERE 句で使用できるようにするため、入出明細テーブルの[入出庫日]も不要となります。

 パターン2と同様、配置するのは 入出明細TO のみで、リレーションは不要です。



 結合にはLEFT JOIN を使用していますが、INNER JOIN も使えます。RIGHT JOIN は FileMaker が非対応のようです。商品テーブルで商品在庫を求める計算フィールド[cSqlLeftJoin在庫数]を追加し、以下のような計算式を組み立てます。

Let (
    $date =
        Case(
            IsEmpty( 繰越情報::繰越日付 ) or UI::g在庫基準日1 < 繰越情報::繰越日付; Date( 1;1;1 );
            繰越情報::繰越日付 = 商品::g在庫基準日1; 繰越情報::繰越日付 +1;
            繰越情報::繰越日付 +1
        );

    Case( IsEmpty( 繰越情報::繰越日付 ) or UI::g在庫基準日1 < 繰越情報::繰越日付; 商品::導入時在庫数;商品::繰越在庫数 ) -

    (
        ExecuteSQL ( "SELECT SUM( \"出庫数量\" ) FROM \"入出明細\" LEFT JOIN \"出庫\" ON \"入出明細\".\"出庫No\" = \"出庫\".\"出庫No\" WHERE \"商品ID\" ="  &  商品::商品ID & " AND ( \"出庫日\" BETWEEN '" & GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "' ) "; ""; "" )
    )
    +
    ExecuteSQL ( "SELECT SUM( \"入庫数量\" ) FROM \"入出明細\" LEFT JOIN \"入庫\" ON \"入出明細\".\"入庫No\" = \"入庫\".\"入庫No\"WHERE \"商品ID\" ="  &  商品::商品ID & " AND ( \"入庫日\" BETWEEN '" & GetAsText ( $date ) & "' AND '" & GetAsText ( UI::g在庫基準日1 ) & "' ) "; ""; "" )

)

 このように商品テーブルの[g在庫基準日1]フィールドと[g在庫基準日2]フィールド、在庫算出用のリレーションに加え、入出明細テーブルの[入出庫日]フィールドが不要となります。また、入出明細テーブルに[入出庫日]を設定するというスクリプトによる面倒な制御も不要になります。


 ExecuteSQL 関数のメリット


 ExecuteSQL を利用すると、本来不要なリレーションやグローバルフィールドを省けるため、データベースの正規化がしやすくなります。また、結合を使用すれば、スクリプトによる余分な制御も不要となります。

 ただ、実行速度的にパターン1~3 のどれが一番有利かは検証が必要です。それについては機会を改めてやりたいとは思っています。



(亀澤)

2013-01-24

FileMaker IWP (インスタントWeb公開) で一覧を表示させる方法

 前回の記事で、インスタントWeb(IWP、Instant Web Publishing)では、一度にリスト表示できるレコード件数が 25 件という制限があるため、リストレイアウトは向いていないというような内容に触れました。

 そこで今回は、FX.php と Web ビューアを使うことによって、IWP 上でリスト表示させる実行方針について紹介します。

 FX.php による検索操作方法は、FX.php のマニュアルをご覧ください。
 以下は、それ以外の部分について簡単に説明します。


1. IWPを使ったページのリロードと印刷方法の情報を流用して、FileMaker Pro レイアウト上に Web ビューアを一つ置き、検索実行用の php ファイルを指定します。

 初期状態は、以下のようにパラメータは無しで指定します。




2. 次に、レイアウト上の“検索”ボタンが実行されたら、指定条件(上記の例では[g氏名fr検])に入力された値をパラメータとして Web ビューアに渡して処理を実行するようにスクリプトを作成します。

 以下は、スクリプト内のWeb ビューアの設定で、URL へ移動するオプションを選択し、検索文字列として $str に格納された検索条件を付加しているところです。


 これにより、“検索”ボタン実行時に、上記の URL に切り替わり、指定された php ファイルの中で検索条件を取り出して FX.php で検索を行い、その結果をリスト形式で展開すれば、その結果リストを照会したり、印刷したりすることができるようになります。


3. ここまで設定し、IWP で表示を確認すると、以下のようになります。。
 ページ上のオレンジ色で示された部分が検索条件指定フィールド、ピンク色で示された部分が Web ビューア(IWP 上ではインラインフレーム)となります。



 [氏名]に「川」を入力して、“検索”ボタンを実行し、「川」を氏名に含む人物を一覧させた場合のイメージは、たとえば以下のようになります。

ご覧のように、氏名の一覧表示が可能となります。

データ作成でズボラをかましてしまいましたので、[氏名]と[ふりがな]に同じものが表示されていますが、これらのフィールドはそれぞれ別フィールドとなっております。




 ピンク色で示したインラインフレームを印刷するようにすれば、一覧をプリンタに出力することができます。


以上

(亀澤)


【IWP関連記事】

【弊社のIWP関連製品・サービス】






2013-01-17

IWP(インスタントWeb)導入の可否

 インスタントWeb(IWP、Instant Web Publishing)とは、FM社公式サイトによると「さまざまなフォームをワンクリックでWebに公開すること」。
 ワンクリックはさすがに言い過ぎと思うが、FileMakerで作成したデータベースのデータを非常に簡単にWeb公開できるのは事実だ。

 同時利用者が数十でデータの照会と検索だけでことたりるシステムであればIWPは有力な選択肢となりうるし、そのような用途であれば海外で多くの導入事例がある(後述)。
 にもかかわらず、FileMaker社(FM社)のIWPに対する立ち位置は微妙な感じ。

 試しにFMの導入事例が紹介されている日米のFM社のWebサイトの「FileMaker カスタマ・ヒストリー(FileMaker Customer Stories)」と銘打ったページを見てみると、iPadやiPhoneの導入事例は数多くあるのに対し、IWPに関する事例が非常に少なく、日本のサイトで1つ、米国のサイトで2つしか見つからなかった。
 これはFM社のIWPに対する立ち位置が微妙なるがため、と思われる。なぜか? 

 上述のように、同時アクセスユーザが数十、かつレコードの検索と照会だけであれば有用なIWPも、いったん、データの入力・更新が要求されると、多くの制約が発生してくる。

IWPの制約

「filemaker IWP」でググると、Top 10 Instant Web Publishing No-No’sなるページリンクが表示される。
 このページは「IWPの禁忌TOP10リスト」とも訳すべきページで、FileMakerではできるのにIWPでは互換性がないまたは実用に適さない機能のTOP10をリストしている。 

 以下意訳、つか編訳。
  1. 新規ウインドウは開けない
  2. 動的値一覧は使うな ― 動作しないことは無いが遅いので使わないが吉
  3. リストレイアウトは使うな ― 使えるが25行しか表示されない、なんでポータルを使おう
  4. 角が丸いオブジェクトは表示不可 - 角丸ボタンは四角で表示される
  5. 条件付書式は機能しない
  6. スクリプトトリガも機能しない
  7. ダイアログ表示のスクリプトも不可 - なんでグローバルフィールドにメッセージ表示するとか
  8. 自動保存オプションも不可
  9. Excel/Word/PDF等のファイルの挿入も不可(fx.phpを使って無理矢理サーバへファイルアップしたり
  10. レコードのインポート/エキスポートも不可
※IWPの制約については、以下のリンクも見てね
FileMaker Instant Web Publishing, Part I: Is IWP Right For You? (英語)


日本はともかく、外国はどうなん?


 上記の制約をみると、IWPの採用に二の足を踏む開発者やWeb担当者は多いと思う。
 減点法ベースの日本人は家電でもAV機器でも、機能がテンコ盛りのモノを好む。目的指向ではなく、減点指向。

 ただ、HTML、JavaScriptやPHPを1行も書かずにWebアプリを作成できる可能性を端から排除してしまうのは、開発コスト、FMクライアントライセンス費を考えるとあまりに惜しい、状況もある。
 では目的指向的、合理主義的な米国ではどうか。

 下図は「FileMaker インスタントWeb」(青)と「FileMaker Instant Web」(赤)の検索件数の比較である。
 青線が100%日本で実行されていてこれが1であるのに対して、赤線は100%米国で実行されていてこちらは23、つまり日本と米国ではIWPへの関心に極端に差があることになる。





 では実際の導入状況はどうか、ググって見た。
 URLに「"fmi/iwp"」を含むサイトを言語別/地域別で検索してみると以下のような結果となる(2013/1/22現在)。

言語別IWP導入状況
サイト言語 サイト数
日本語 220
英語 4,040
全言語 5,180
地域別IWP導入状況
地域 サイト数
日本 448
米国 2,190
全地域 5,180
注:図にはイントラネットや検索エンジン忌避対策を施しているサイトは含まれない。


 対英語比では約18倍、対米国比で約5倍(人口を考慮すると約2倍)、導入状況に差がある。

で、どういうときに使うん?

実際問題、IWPはどういうときに使えるのか。
 「アプリの性能よりも開発工数を抑え、コストを抑えることが第一」、「Webアプリを社内開発したいが、PHPやASPXの技術者を養成または雇用するのは厳しい」という方、以下を参考にしてみてはいかが。
  1. 高速なアプリを求めない
  2. IWPはFileMakerのスクリプト(実行可能スクリプトステップに上記の制限あり)でしか制御できないのため、実行速度を上げるたの作り込みができない。IWPに関する経験値が不足している場合、プロトタイプを作成して最低限の実行速度が出るかテストを行うことも必要。

  3. 高度な可用性を求めない
  4. 24時間/365日稼動みたいなシステムには使用しない。何かあったら、関連サービスを再起動できるような余裕がないと…

  5. 大規模なシステムにならない
  6. レコード数が数百万を超えるようなものは…、避けよう。

  7. Coolなユーザインタフェイスを求めない
  8. 上述のような制約があり、またJavaScriptをページに埋め込みブラウザを制御するようなこともできない(WebViewerを使うという抜け道がないこともないが…)。GoogleのようなCoolなインタフェイスを求めても無理。
 上記条件に合致し、IT責任者が今回はIWPの導入が適切と判断しても、「黙って俺について来い!」といえないような環境では、本開発の前にプロトタイプを作成して、関連部署のコンセンサスをとることも必要となるのだろう。


世界の大学や公共機関で使われるIWP

 ということで、目的合理性を解する大学、研究機関や政府・公共機関でIWPが使われていたりする。



以上

(土屋)



参考サイト:
全国90拠点、グループ社員5,000名が利用するWeb社内販売システム(日本のIWP導入事例)
Coach Source — A Fountain of Wisdom(米のIWP導入事例)
FileMaker Instant Web Publishing, Part I: Is IWP Right For You?
FileMaker Instant Web Publishing, Part II: Five Top Tips for Success



【IWP関連記事】

【弊社のIWP関連製品・サービス】