今なお輝くFileMaker 5.5/6

FileMaker 5.5/6の環境を新サーバへ早急に移行する必要がある方へ

FileMakerのWindows OSとの互換性や注意点などをこちらの記事にまとめました。
(2021/07/25 NuckyT)

 今なお輝くFileMaker  5.5/6！　その理由は以下の通りです。

1. OS上位互換性

当社の経験上、FileMaker Pro 5.5/6（以下、FM5.5/6） は最新の Windows OS ― Windows 7/8/8.1/10で、FileMaker Server 5.5（以下、FMS5.5） は Windows Server 2008/2008R2/2012/2012R2 で動作します。また、FMP5.5/6 のマルチユーザライセンスを Windows Server のリモートデスクトップサーバ上に配置すれば、遠隔地からでも FMS5.5にアクセスして快適にFMを使用できます。
当社の取引先では、2台の Widnows Server 2008 を2008年に導入し、1台に FMS5.5 を、もう1台（Remote Desktop サービスライセンス×10ユーザ付）に FMP5.5(マルチユーザライセンス) をインストール。2016年5月現在、20ユーザがこのシステムを利用しています。
ちなみに、FM5.5のリリースが2001年。最終のアップデートがリリースされてから約15年が経過した2016年現在でも最新のOS上で普通に動作する FileMaker 5.5/6 は驚異的ですらあります。
（追記：2020年3月現在稼働中）

注：

•  2019年3月現在、当方及び取引先の Windows 10 機で FMP 5.5/6 が起動・動作することを確認しています。
• 当社ではブログのコメントにより寄せられるレガシー FileMaker の動作情報を歓迎致します。それらの情報は参考にさせて頂き、当ブログに反映させて頂くことがあります(19/3/13追記)。
• FMS5.5 は環境によっては問題が起こることもあります。当方で遭遇した現象としては、Dell PowerEdge T105 のハイパーバイザ上の仮想マシン（Windows Server 2012R2 ）では、 FMS5.5 は問題なく動作していましたが、PowerEdge R330 のハイパーバイザ上の仮想マシン（Windows Server 2012R2 ）に FMS5.5 を新規インストールした後にFMS の コンソールで「ファイルメーカー Server」を右クリックして「プロパティ」を選択するとコンソールがクラッシュする、ということがありました。　この時、正常稼働している PowerEdge T105 上 の仮想ディスク（VHD）を丸ごと PowerEdge R330 にコピーして仮想マシンを再構成したところ、コンソールで「プロパティ」を選択することができました。R330 上に新規インストールした FMS5.5 を動かすべくいろいろ試してみましたが成功せず。 本現象は両PowerEdge のビデオドライバの差異に起因するものかと疑っています。

Windows 10 上の FMP5.5 によりデータベースを起動

2. 低コスト性

これが第二の理由です。　どの位、システムの総コスト（TCO）が安いのか、FileMaker 15 の FLT との比較で試算した結果が下記です。

• FMP5.5@￥35000× 20ライセンス+FMS5.5 ￥130,000×1台＝￥830,000
• FileMaker 15 FLT　20ユーザライセンス）@￥285,000×15年＝￥4,275,000

何と FM5.5のコスト は FLTのそれに比し、 5分の1以下。これまた、驚異的です。今後、Windows 10 と Windows Server 2016でも安定運用できそうな予感が…。　そうなるともう10年はかるーく生き残りそうです。

［19/03/17追記］
2019年3月現在、当社環境では Windows 10 上の FMP5.5/6 により開発・運用を行っています。また、複数の取引先に納品した FMP5.5/6 及び FMS5.5 によるシステムが、Windows 10 を含む新しいOS上で稼働しています。 仮想マシンや P2V、Remote Desktop を使用すれば、今後10年以上、レガシーFileMaker によるシステムは運用可能と思われます。


3.高速性

最新の FileMaker は最新のマシンで起動させてもかなりモッサリ。 一方、FMP5.5/6 を最新のマシンで起動させた時の速いことと言ったら…　お暇なら古いPCと最新のPCで実行速度を比較してみてください。

FileMaker のOS互換性やFM製品間の互換性、さらにライセンスポリシーも迷走する昨今、機能的には遥かに劣る FM5.5/6 が輝いて見えます。　次回は、そんな  FM5.5/6 のアプリを iOS や Android で利用してみます。

そのアップグレード、ホントに必要？

 　FileMaker は Ver5.5/6 以降、様々なアップグレードがなされてきました。
大きいところでは、

• データベーススキーマの変更（アプリとデータの分離が可能に）
• イベントによるスクリプトトリガ
• データベース容量の拡張
• アカウント機能追加（スクリプトによるアカウントの新規作成・管理）
• マルチウインドウ対応とウインドウの制御
• サーバサイドスクリプト
• PDF出力
• ESSによるSQLデータソース（RDBMS）との連携
• WebDirect（FMアプリをそのままWebアプリ化）
• カスタムWeb機能の充実（XML/PHP/REST対応）
• iOS対応
• テーマ・スタイル/タブ機能等レイアウト機能の改善
• デバッガの改良

が挙げられます。現在、それぞれ重要な機能となっており、大きな恩恵を得ているユーザや開発者も多いでしょう。
一方、巷には、機能的なアップグレードを必要としない、或いはアップグレードが費用対効果に見合わないシステムが数多あります。 たとえば、NTT東日本の「ひかり電話設定サイト」（下図）、このサイトでは電話転送の設定を行うのですが、ここのユーザインタフェイスはこの10年程、ほとんどまったく変化がありません。

また、Googleの運営する Blogger　― 当ブログもこれを利用しています ―、このブログ投稿管理サイトも“ユーザインタフェイス”的には十数年、あまり変化がありません。

上記の2サイトは、ユーザサイドから見れば改善の余地がありますが、運営企業は「費用対効果が低い」、あるいは「プライオリティが低い」とみなしてか、少なくともユーザインタフェイスのアップグレードにはあまり熱心ではないようです。

かく言う小社も、顧客管理・請求書発行業務は「売上猫くん4.0」という FM4.0 で作成した自社システムを FM5.5 によりアップグレードし、一部簡単な機能を追加した後は、ほぼ20年間そのまま使用しており、今後も使用を続ける予定です。

FileMaker 5.5/6 で現在も稼働する小社の基幹「売上猫くん 4.0」

Amazonの通販サイトや AWS、 YouTube、Google Map、Google Analytics のように持続的なアップグレードが企業競争力と収益の源泉となるようなシステムは星の数ほど存在します。 一方、レガシーシステムであっても十分に役割を果し、今後も大規模なアップグレードを予定しないシステムも多く存在するのです。

本ページは現在でも多くのアクセスがあり、レガシーFMへの関心がいまだに高いことがうかがえます。システムをアップグレードするか、延命するかについては、業者やベンダーの情報を鵜呑みにせず、そのアプリの性質や将来像、費用対効果、双方のリスクを踏まえて意思決定するのがクレバーな企業なのだ、と思うのです。

(19/03/27追記　NuckyT)

（土屋）


追記
些細な変更にすらリスクは伴います。重要なシステムであればあるほど、そのまま使いたい。　アジャイルでリファクタリング…って何？　触らぬ神に祟りなし。
米軍の核兵器運用システムでいまだに8インチフロッピーディスクを使う理由について、ペンタゴンは「…現在も機能しているため」と言っています（米軍、核兵器運用に今も8インチフロッピー使用）。

2020/02/04 追記：
米軍、核ミサイル運用でのフロッピーディスク使用をようやく停止との報道
The US nuclear forces’ Dr. Strangelove-era messaging system finally got rid of its floppy disks （英語）
2019年にフロッピーディスクがようやく廃止されたとのことですが、約50年前のテクノロジーを延命運用できるとは、さすが米軍。

■ FileMaker 5/6等レガシーシステム関連記事

正月休み明け、仮想マシン上の FileMaker Server 5.5 バックアップが失敗していた(22/01/25投稿)
仮想マシンの外部ディスクでI/Oエラーが出た際の復旧方法

まだまだいける FileMaker 5.5/6　― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる！ ― 後日談FileMaker（17/09/07投稿）
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる！（17/04/25投稿）
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う（16/05/25投稿）
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6（16/05/23投稿）
レガシーFileMaker の意外な利点。

新WebDirectのパフォーマンスについてあれこれ

　FileMaker 13 の WebDirect (以下、WebDirect 13) と比べ、FileMaker 14 の WebDirect (以下、WebDirect 14) のパフォーマンスはどれだけ向上したのか？実用に耐えるレベルになったのか？
　WebDirect 14 の導入を検討するにあたり、これはとっても気になるところです。

　FileMaker 社の公式サイトでは、WebDirect の起動スピードは以前より 25% 向上していると謳ってはいます。また、独自にパフォーマンスの比較検証を行って公開している方（会社）もおいでで、そうした情報はとっても貴重です。

　ということで、パフォーマンスについて情報を公開している方の情報を例によって渉猟してみました。　（あと、人様の情報を紹介させて頂くだけでは申し訳ないので、弊社でも WebDirect のパフォーマンスの検証をしてみました。）

米国 FileMaker 社（パートナー）が公開している YouTube ビデオ

　かの有名な  Richard Carlton Consulting Inc. の FileMaker Training Videos Channel という動画です。

　WebDirect関連のビデオでは 「第一部：FileMaker WebDirect 14 のご紹介」、「第二部：WebDirect の最適化方」の 2 本が公開されていますが、その中からパフォーマンスに関する情報を拾って要約しました。

「第一部：FileMaker WebDirect 14 のご紹介」　Introduction to FileMaker WebDirect 14

　WebDirect がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

1. 11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
2. 13:40 WebDirect 14 によるレコード移動時の表示速度デモ
3. 15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
4. 16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている。
5. 20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている！（WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。）。
6. 27:28 WebDirect は ChromeBook の動作保障をしていないが、自己検証ではサクサク動いた。

（動画は英語）

　

　特に　15:13 あたりの WebDirect 13 vs WebDirect 14 レコード移動速度比較実験は必見！
　ウィンドウを左右に並べて比較しているので、速度が向上していることは一目瞭然にわかります。

「第二部：WebDirect の最適化」　Optimaizing Solutions for FileMaker WebDirect 14 

　2013年の Richard Carlton Consulting Inc. の FileMaker 13 WebDirect Overview and Optimization Presentation と基本的な流れは同じですが、 WebDirect 14 に関する情報にも触れられています。

パフォーマンスに関する重要ポイント（リンクはタイムスタンプ）：

1. 17:55 *.fp7 ファイルを  FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
   これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
   サイズが約半分ということは、転送速度が約2倍になっているといえる。
2. 18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
3. 19:55 WebDirect 13 で共有スタイルで最適化したレイアウトサイズは 480kb だったが、 WebDirect 14 で同様の作業を行うと 425kb で、 約15% スリム化されていることがわかった。

（動画は英語）

 　今回は WebDirect のパフォーマンス比較がわかるところのみを中心にご紹介していますが、ビデオの中では以下のようなことにも触れています。

WebDirect 13 の最適化ビデオと重なる情報は省いてあります。より詳しい情報をご覧になりたい方は、FileMaker 13 WebDirect Overview and Optimization （英語）をご覧いただくか、弊社記事 WebDirect 開発の勘どころ をご覧ください。

画像について 

　ｊpeg, png などの画像利用は最小限にする。
　FileMaker Pro 14 には軽量の SVG ビルトイン画像（glyph）が用意されているので、これを使ってボタンアイコンを装飾することを検討。
　※SVG = スケーラブル・ベクター・グラフィックス

タブ・スライドコントロールについて

　タブ、スライドコントロールの使用もできるだけ避ける。
　必要のない情報をロードさせないのが基本。
　タブコントロールを配置するれば、裏でタブ上のすべての情報がロードされることに注意。

ポップオーバーについて

　FMP13 で導入されたポップオーバーも要注意。
　ブラウザに別ウィンドウを表示させる代わりに使えるが、多用は避けること。
　裏であらかじめすべてのポップオーバーデータをロードすることには変わりはない。

スクリプトトリガについて

　WebDirect 側にはスクリプトエンジンが搭載されていない。
　このため、イベントが発生するたびに FileMaker Server にアクセスして処理を決定する。
　当然、スクリプトをトリガさせるイベントがたびたび発生すれば、その分のトラフィックが増加する。
　このトラフィックコストはできるだけ少なくした方がよい。

FileMaker WebDirect 14 のパフォーマンス最適化については、「FileMaker 14 WebDirect ガイド」の 14 ページ「ステップ 3: パフォーマンスの最適化」（PDF）にヒントが掲載されています。こちらも併せて読むと、参考になると思います。

---

土屋企画による WebDirect パフォーマンス検証

 

 小社でも『FMEasy在庫 IWP/WD R1.5』 という製品を使い、社外と社内の2つのサーバでテストをしていました。

■実行環境
社外：米国某ホスティングサービス(VM/共用タイプ)、16 GB RAM/Xeon E5 4 cores
社内：自社サーバ（VM/占有タイプ）、4GB RAM/core i7（4プロセッサ割り当て）
FileMaker Server： Ver14.0.2（サーバ1/サーバ2共に）
使用ブラウザ：主としてIE10、IE11
注：VM＝仮想マシン

■テスト内容
　予め、連続ビュー、連続更新、出庫伝連続伝票作成、という3つのループスクリプト（後述）作っておき、5～10個のブラウザウインドウからこれらのスクリプトを実行しています。
　で、こんな感じになります。

　上図は、1台のPC上で10個のIE10ブラウザウインドウを開き、ループスクリプトを実行していますが、Remote Desktop （RDT）で複数のセッションを開き、それぞれのセッションで1～複数のブラウザウインドウを開いてループスクリプトを実行というテストも行っています。
　後述の「■テスト」の項では、＜社内/1PC/複数ブラウザ＞、＜社外/複数RDT/1ブラウザ＞などと表記しますが、前者は社内サーバに1台のPCから複数のブラウザウインドウを起動しアクセス・テスト、後者は社外サーバに複数のRemote Desk Top から1つのブラウザウインドウを起動してアクセス・テスト、を表しています。

■ループスクリプトの内容
1. 連続ビュー
上図の出庫画面で先頭レコードから1件づつ後方へ移動していく。移動直後に0.2～1秒ポーズし、50～100件目に到達したらメッセージを出して終了する。

2.連続更新
上記の連続ビューと基本は同じだが、移動直後に備考フィールドに実行時の日時を追記する。

3.連続伝票作成（クライアントサイド）
出庫伝票形式のデータを連続して100件作る。といっても、1出庫レコードには25の出庫明細レコードが付属しているので、このスクリプトを1回実行すると、出庫レコード100件+出庫明細レコード2500（25明細×100）件、計2600のレコードが作成される。

4.連続伝票作成（サーバサイド）
仕様は上記4同じだが、サーバサイドスクリプトで実行。

■テスト
1.連続ビュー　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続ビューを実行し、すべてのブラウザでエラーなく成功。


以下の動画は、撮影の都合上、6つのブラウザで実行しています。

2.連続更新
2-1　 連続更新　＜社外/1PC/複数ブラウザ＞
10個のIE10ブラウザウインドウで連続更新を実行し、全てで成功。但し、上記1よりは時間がかかる。

2-2　連続更新による影響　 ＜社外/複数RDT/1ブラウザ＞
6つのRDTで1つのブラウザを起動し、それぞれで連続更新スクリプトを実行させた後、ローカルでブラウザを起動し、テスト実行者が手動によりレコード移動や入力を行いました。　これは、他のユーザが入力作業をしていると、どのような影響を受けるかシミュレートしたものです。結果は以下の通りです。

• 6つのRDTの連続更新は時間はかかるもの成功します。
• ローカルのブラウザでは入力は成功するものの 、レコード移動ボタン（＞アイコン）を数回クリックすると、サークルアイコンが現れ操作ができなくなる現象が頻発します。数分待つと画面が表示されますが、これでは実用に耐えないレベルです。　
  

2-3　連続更新による影響　 ＜社内/複数RDT/1ブラウザ ＞
上述の2-2 と同様テスト内容を 社内サーバで実行したときの模様です。

• 今回は、ローカルで新規レコード入力操作中にサークルアイコンが現れ、その後 15 分経過しても状況が変わらなかったため、テストを中断しました。
• このサークルアイコンが現われ操作不能になる現象は今回のループテスト実行中に何回も発生しました。　サーバ性能を上げるとこの現象は緩和されるのかもしれませんが、性能を上げたとしても FileMaker Pro 並みの安定運用を行うのは厳しいのではないかと思われます。　

2-4　連続更新を24セッションで実行 ＜社内/複数RDT/複数ブラウザ ＞
4つの RDTクライアントでそれぞれ5つのIE10ブラウザウインドウを開き、さらにローカルで4つのIEブラウザウインドウを開いて（計24セッション＝4×5+4）て連続更新スクリプトを実行。成功したのは24セッション中9、残りの15セッションはサークルアイコンが出現し制御不能に。

3.連続伝票作成（クライアントサイド） 　＜社外/1PC/1ブラウザ＞
1つのIE10ブラウザウインドウで成功。所要時間は43秒。但し、再度実行すると、ブラウザが反応しなくなる（下図）。

4. .連続伝票作成（サーバサイド）　＜社外/1PC/1or 5ブラウザ＞

1つのIE10ブラウザウインドウで数秒で成功。但し、実行直後から全くブラウザが反応（上図と同様）しなくなることがある。
バグを修正したところ、上記打消し線部の問題は解消。　5つのブラウザウインドウ上で本スクリプトを同時実行したところ正常終了。さらに、続けて5つのブラウザで同スクリプトを実行したところ、こちらも問題なく終了。
※バッチ処理は実行速度と安定性から、利用可能であればサーバサイドスクリプトを利用するのが良い

※　今回のテストを通じて思ったこと　―　WebDirect導入時の注意点

1. 複数のブラウザでループスクリプトを実行しても（動作は遅くても）比較的に安定して動作する。
2. ユーザが ＜ や ＞ （レコード間移動）ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。 ＜ や ＞　を連続押しすると、この現象は高い頻度で発生する。
3. レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる（サークルアイコンが出っ放し状態）になることがある。
4. サーバサイドスクリプトが実行できる状況であれば、使う

上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記2の現象に関し、WinMTR の結果をホスティング会社に送付し問い合せたところ、「some severe packet loss and latency from you location in Japan to our location」とのことでした。　ただ、サークルアイコン出っ放し状態の時でも、FileMaker Pro によりサーバにアクセスして ＜ あるい ＞ をクリックすると、速度は遅いものの正常に動作すること、社内サーバを使用してもサーバへの負荷を高めるとサークルアイコン出っぱなし現象が発生することからみて、WebDirect にはまだ問題があると思います。
　尚、小社のLAN内のWebDirect環境では、ブラウザの　＞ または ＜ 　ボタンを連続押ししても、上記の問題は発生していません。  

　以上のことから、WebDirect の導入に際しては、サーバ性能（メモリ/CPU）に加え、ネットワーク環境にも十分注意を払う必要があります。実際の運用環境にできるだけ近い環境を用意し、事前に十分なテストを行うことも必要でしょう。　またテストを行う際も精度の高いプロトタイプを用意し、十分な実行速度が確保できるかもチェックしたいところです。ブラウザ上の ＜ と ＞ （ナビボタン）を非表示にしたり、短い間隔で連続実行できないようにするなどの工夫も必要かもしれません。　導入担当者または開発者は、サークルアイコンの地雷を踏まぬよう、十分注意しましょう。

注：
「社内サーバのスペックが低すぎるのがサークルアイコンの原因だろ？」とお思いの各位、御尤もです。メモリたっぷりなサーバを調達してテストしてみたいです。　ただ、サーバ性能が低いにしても、サークルアイコン出っぱなしはオカシイと思います。

---

WebDirect のパフォーマンスに関するその他の情報

　バージョン間での WebDirect パフォーマンス比較を実際に行っている開発者は残念ながらまだ少ないようです（公式サイトの 25% 速度アップについて言及していらっしゃる方は多いでのですが）。

　そんな中、米国の FileMaker Forum ではいくつかのスレッドで WebDirect のパフォーマンスに関する情報がみつかりました。
　リンク先は英語ですが、スレッドの紹介程度に要約を載せておきます。

1. FileMaker Server 14 & WebDirect Performance

　NickLightbody という方が WebDirect 1ユーザあたりの消費メモリを計測して表にされています。
　こちらのスレッドでは、3 WebDirect ユーザ の場合は 100MB の RAM　を消費し、 30 ユーザでは 1 GB の RAM を消費することを挙げたうえで、独自の計測結果も公開されているのでとても参考になります。　すばらしい！　＼(＾o＾)／

2. FMS 14 WebDirect Performance?

　WebDirect 14にアクセスしたところ、ロード中のアイコンが出っぱなしになり、10～20 秒後にログイン画面に戻ってしまうという現象が発生。

　ちなみに、当方でも同じ現象に遭遇したことがあります。
　ホスティング会社にこの件について問い合わせたところ、FileMaker Server 13 から発生している既知の現象で、この現象が発生した場合は、FileMaker Server を再起動しないとどうにもならないとのことでした。
　また、この現象はいまのところ FileMaker Server 14 でも発生しているので、今後のアップデートが望まれるところです。　早く出さんかいヽ(`Д´)ﾉ

　その他の WebDirect 関連記事を読む

（亀）

WebDirectの導入事例を渉猟す

　WebDirect の導入に際してやはり気になるのは先行する導入事例。　
　小社でも時たま導入事例の紹介記事を探していますが、記事は多くありません。

　FileMaker 13 の WebDirect は、FileMaker Pro レイアウトのレンダリングが魅力的である反面、動作条件の厳しさ（高スペックなハードウェアの要求）、デザイン時に考慮すべき点の多さ、実行速度の問題など、機能的にはまだまだ発展途上という感じでした（これらの問題については、WebDirect 開発の勘どころ　をご参照ください。）


　そんな折、2015年5月13日に FileMaker 14 が発売になりましたが、やはり WebDirect の進化に注目が集まるっているようですね。

　ということで、小社では改めてWebDirect(WD)の導入事例を探してみました。
　以下は見つかった記事の要約、編訳となります。　

※WebDirectが2013年12月にお目見えしてから1年半。まだまだ導入事例は少ない感じです。Ver14で状況は変わるのでしょうか。

【WebDirect の導入事例】

1. Braun Electric Company, Inc. （米国カリフォルニア州）

　電設会社。
　435人以上の従業員の安全を FileMaker Go for iPad/iPhone で管理。
　SeedCode 社の GoMaps プラグインを併用し、従業員の現在地を GoogleMap で確認。

　今後は複数の業務処理の自動化に向けて、WebDirect を導入していく“予定”とのこと（予定なんで、これ、全然導入事例ではないです。GoMapsがCooｌそうなんで、思わず載せました。すみません）。

　参照元：http://www.filemaker.com/solutions/customers/stories/braun-electric-company.html　
　参考リンク：　GoMaps プラグイン（英語）

2. Annex Medical, Inc. （米国ミネソタ州）

 　医療用精密機器製造会社。
　従業員数 20人。
　社内のシステムを FileMaker Go for iPad でフル活用。
　品質記録、検品、工数管理、原料管理、在庫管理、配送、送り状作成までをトータルに行っている。

　作業効率化のためにダッシュボードをWebDirect で公開し、従業員の作業工数をチェックできるようになっている。 

　参照元：http://www.filemaker.com/solutions/customers/stories/annex-medical-inc.html

3. Cure Kids (ニュージーランド・オークランド)

　児童健康研究所。

　乳幼児突然死のリスク計算アプリを WebDirect メインで開発。

　データ入力を行うと、瞬時に死亡率のリスク計算ができるところがウリ。　
　開発期間が数週間だったにもかかわらず、ここ一年間で大きな修正はない。
　今後はカスタム開発を行い、ソリューションを完全レスポンシブな Web アプリケーションに発展させる予定（うーん、このWDソルーションはCWPソルーションに置き換わるのか。　WDで超高速開発して急場を凌だり、あるいはWDでプロトタイプを作成してエンドユーザに試用してもらう。で、本番システムはCWPで開発、みたいな）。

　参照元：http://www.teamdf.com/work/cure-kids
　開発元：http://www.teamdf.com/

---

【WebDirect 導入の具体例を示しているエンドユーザ】

1. Beko BBL　（ドイツ・ケルン）

　プロバスケットボールリーグ。
　32 人の審判と 10 人のスタッフ監督で運用中。

　全国バスケットボールリーグの所属審判を WebDirect および FileMaker Go で管理。

　（動画はドイツ語）

　
　スケジュール、評価、目標達成度、その他要素を含むすべての関連データを iPhone またはiPad で審判に公開。
　審判は、どこにいても iPhone または iPad を使い、 WebDirect　や FileMaker Go 経由でシステムにアクセスしてデータ入力可能。
　
　一元管理された目標達成やその他要素を含む情報は、リーグ管理者および審判が人選に利用。

　FileMaker プラットフォームで審判データベースを開発することにより、人材管理を実現。
　所在地情報をはじめ、年間出場試合数、身体データ、資格情報、関連情報、一般・技術審判の区分などを含む試合関連情報に関する個人データを管理。

　参照元：http://www.filemaker.com/de/solutions/customers/stories/bbl.html　

2. Akubra Hats （オーストラリア・ニューサウスウェールズ州）

　服飾品製造業。
　
　生産管理・受注管理に会計パッケージを統合させたシステムを FileMaker プラットフォームで開発。
　新たに導入されたレポート機能によって、季節ごとの商品在庫レベルを把握しやすくなり、在庫回転率が向上。
　早期受注にも対応でき、受注状況の確定も迅速化。

　システム導入後、一年間で受注レコード 2万件（受注明細レコード数 25万件、関連サイズ別レコードも含めると 56万件）を管理。
　工場および事務処理の一日 20 時間相当の業務をこのシステムで実現。
　今後のシステム最適化により、さらなる業務効率化が期待される。

　FileMaker Go と FileMaker WebDirect の併用により、モバイル顧客および遠隔顧客のニーズにも対応。
　また、2015 年の小売業者向けオンライン受注システム導入に向けて WebDirect によるモジュールをテスト運用中。


　参照元：http://www.filemaker.com/au/solutions/customers/local_stories/akubra-hats.html
　

3. サンラモン市街化区域（スペイン）

　都市開発事業。

　マドリードの民間開発区域、サンラモン市の 2000人の居住者を、18人の従業員により24時間体制で監視するシステムを運用。
　一日 3 シフト制でサンラモン市内を監視。
　訪問者・車両登録処理を含め、地域の安全を目指すのが基本目的。
　
　FileMaker Go および WebDirect によるアクセス。

　email を利用した居住者自宅訪問の実現。
　FileMaker Go for iPad を使ったレコード承認、訪問スケジュール管理
　WebDirect を使った居住者データベース管理
　
　より安全でシンプルな承認作業と堅牢なアクセス管理を実現。

　居住者に公開しているデータベースは二種類。
　居住者連絡先詳細データベースは地域事務所が WebDirect を使って更新。
　登録車両情報データベースは居住者自身が編集可能。

　訪問者がある場合は、e-mail または SMS で訪問者情報を監視員に送信。
　これにより 訪問者登録に要する時間を98% 削減。

　FileMaker Go for iPad による訪問者登録処理が可能になり、業務が簡略化されるとともにセキュリティログの記録量が 300% 増加。


　参照元：http://www.filemaker.com/es/solutions/customers/local_stories/Ciudad_San_Ramon.html

---

【WebDirect を使ったソリューションを提供している業者の開発例】

1. Contraflow （オーストラリア）

　道路交通網関連団体の計画作業と管理サービスを提供するシステムを構築。
　150人の従業員による内勤作業・オンサイト作業の両方に対応したあらゆる管理業務向けのソリューション。

　25 人の FileMaker Pro ユーザ、80人の FileMaker Go ユーザ、関連会社 5 社による WebDirect アクセスによりシステムを運用。

　【導入効果】
　コンプライアンスと安全性の向上、監査時不適合案件の減少、
　ワークフローのペーパーレス化。即時更新、各ステージの時間短縮、
　カオス化の完全排除、効率化されたプロセス、　自動 SMS 送信により電話による通話を廃止
　拠点呼び出しの時間と労力の削減、給与計算の自動化
　回転率の予測作業の迅速化と単純化、人員管理、必要車両とVIP 客の特定


参照元： http://info2.filemaker.com/Contraflow_Contraflow.html

2. SeedCode Calendar for WebDirect　（米国）

　WebDirect 対応の FileMaker Pro 向けカレンダープラグイン。
　カレンダーの週間表示、月間表示、　テーマ切替、ガントチャート表示などに対応。

（動画は英語）

　その他詳細は SeedCode 社の製品ページをご参照ください。
　SeedCode Calendar for WebDirect

弊社でも FileMaker 13 版 WebDirect 対応の在庫管理テンプレート製品『FMEasy在庫IWP/WD R1.5』を販売しております。

FMEasy在庫 IWP/WD R1.5 製品紹介ページはこちら
 
※この動画には WebDirect の動画部分は含まれていませんm( _ _ )m　インスタントWeb（IWP）の動画となっております。　14も出たことだし、WD部分の動画も作ろうか、と思う今日この頃です。
 　

　その他の WebDirect 関連記事を読む

(亀)

ファイル起動時にFileMakerからMySQLに投げられるクエリ

FileMaker Pro をフロントエンド、MySQLを バックエンドにしたアプリを起動する時には、以下のようなクエリが投げられるんですね。　
（FileMaker Pro 13使用時）

SET NAMES utf8　［参考URL］

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, “future incoming messages from this client are in character set cp1251.” It also specifies the character set that the server should use for sending results back to the client.

A SET NAMES 'charset_name' statement is equivalent to these three statements:

SET character_set_client = charset_name;
SET character_set_results = charset_name;←A
SET character_set_connection = charset_name; 

SET character_set_results = NULL　［参考URL］

If you want the server to perform no conversion of result sets or error messages, set character_set_results to NULL or binary: 

SET SQL_AUTO_IS_NULL = 0　［参考URL］

If this variable is set to 1 (the default), then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form:

SELECT * FROM tbl_name WHERE auto_col IS NULL

If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function.

つまり、INSERT直後、 AUTO_INCREMENT値は存在するにもかかわらず、IS NULL として認識されるというもろ刃の剣。

SET AUTOCOMMIT=0　 [参考URL]

The autocommit mode. If set to 1, all changes to a table take effect immediately. If set to 0, you must use COMMIT to accept a transaction or ROLLBACK to cancel it. By default, client connections begin with autocommit set to 1. If you change autocommit mode from 0 to 1, MySQL performs an automatic COMMIT of any open transaction.

set @@sql_select_limit=DEFAULT 　［参考URL］

The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server allows per table, which depends on the server configuration and may be affected if the server build was configured with --with-big-tables. Typical default values are (2³²)–1 or (2⁶⁴)–1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.
If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.
sql_select_limit does not apply to SELECT statements executed within stored routines. It also does not apply to SELECT statements that do not produce a result set to be returned to the client. These include SELECT statements in subqueries, CREATE TABLE ... SELECT, and INSERT INTO ... SELECT.　
※うちのDEFAULTは、 (2⁶⁴)–1=18446744073709551615　でした。こんなん返されても困るわ。

SET SQL_MODE='STRICT_ALL_TABLES'　［参考URL］

For transactional tables, an error occurs for invalid or missing values in a data-change statement when either STRICT_ALL_TABLES or STRICT_TRANS_TABLES is enabled. The statement is aborted and rolled back.

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

INFORMATION_SCHEMA から、アプリで使用さているビューを含むテーブル情報を取得。

select database()

接続中のデータベース名を返す

describe `郵便番号`

当該テーブルのコラム情報を取得

SHOW KEYS FROM `easyinv15`.`郵便番号`

プライマリ等キー情報を取得、Cardinality ってここにあるのね。


SELECT TABLE NAME ～　から SHOW KEYS ～　（イタリック部）は、FileMaker ファイル内に登録されたすべてのMySQLシャドウテーブル（ビュー含む）に対して実行される（ｷﾘｯ


（土屋） 

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one

The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:

Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.

1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.

	Common Model	BTHM	Remarks
Fast development	Yes	No
Ease of operation	Good	No so good
Performance for big tables	Very poor	Good
Weird behaviors	Many	Minimum
Records order	Weird	OK	Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya

『FMEasy在庫』 のバックエンドを MySQL に変える（２） ― 在庫

　本稿では、リリース予定の『FMEasy在庫 on MySQL R1.5』（仮称）の商品画面の在庫に関して説明いたします。

　以下が商品画面となります。

　『FMEasy在庫 on MySQL R1.5』では、2つの方法で在庫を算出します。
　一つは「SQL Update方式」、もう一つは「FM計算方式」です。

　それではそれぞれに関して説明します。

SQL Update方式

※特徴
　この方式は“実行”ボタンをクリックすることにより、［在庫基準日］時点の全商品の在庫数を算出して記録します（技術仕様的には、入庫数計/出庫数計/在庫数を「upd在庫」という専用テーブルに記録します）。

　一旦記録されたデータは次に“実行”ボタンを実行するまで更新されません。
したがって、“実行”ボタンクリック時点には最新情報ですが、時間が経過するに従い、最新の在庫数とは異なる可能性が高くなります。

　“実行”ボタンクリック時に入出庫データが大量にある場合、処理に数秒～数十秒、1千万件を超えるような場合は数分かかる可能性がありますが、処理が終了してしまえば即座に数値を表示・印刷できます。
　「SQL Update方式」は、在庫表などで在庫情報をリスト形式で表示・印刷する場合、高速に処理することができます。

注：
　本機能はクライアント/サーバ環境に置いて、FileMaker ServerにODBC設定がされていれば、FileMakerクライアントにはODBCのインストール/設定は不要です。

※操作方法
　実行ボタン　―　任意の［在庫基準日］を指定して本ボタンを実行すると、［在庫基準日］時点の入庫数/出庫数/在庫数が算出・記録されます。

　当方のクライアント/サーバ環境下で、入出明細レコード170万件に対してこの処理を実行すると、30秒～1分程度の時間を要します。

　作成済在庫データ選択ウインドウ（FileMaker 13使用時のみ）　―　実行ボタン右横の黄色の部分をクリックすると、小さなウインドウ（下図）が表示されます。この時、プルダウンメニューをクリックすると、他のユーザ（アカウント）が作成した在庫データの一覧が表示されるので、ここでその内の一つを選択すると、以後、「SQL Update方式」には選択したアカウントが作成した在庫データが表示されます。

他のアカウント(admin/seminar/stockchecker)が作成した在庫データを照会できる。
アカウント右側の日付は、データ作成時に指定した［在庫基準日］

注：
　各ユーザ（アカウント）は［在庫基準日］を指定して“更新”ボタンを実行することにより、全商品の在庫データを作成・記録できます。
同アカウントが次に“更新”ボタンを実行すると、前回作成した在庫データは上書きされます。例えば、admin アカウント で［在庫基準日］に「2014/11/27」と指定して本ボタンを実行すると、全商品に対して［在庫基準日］時点の在庫データが作成されますが、次に adminアカウントが「2015/12/31」を指定して同操作を実行すると、「2014/11/27」時点のデータは上書きされます。

　尚、他のアカウントが作成した在庫データは上述の通り照会することはできますが、別のアカウントで上書きすることはできません。例えば、adminアカウントでログインしている場合、seminar が作成した在庫データの照会はできても、上書きすることはできません。

FM計算方式

※特徴
　この方式は旧来のFileMakerの計算式を使用した在庫算出方法（参考記事）です。この方法のメリットは、常時最新の在庫情報を表示される点です（下記注参照）。

　ディメリットは、入出庫明細にデータが多量にある場合、在庫情報の表示に時間がかかることがある点です。 例えば、入出明細レコードが170万件あり商品Aを含むレコードがその中に2万9千件ある場合、当方の低SPECなクライアント/サーバ環境下では商品Aの［在庫数］を算出するのに5秒強程かかります。

　商品画面で個々の商品情報を一つ一つ計算・表示する場合はまだいいのですが、複数の商品の［在庫数］をリスト形式で表示する場合はかなりのストレスを感じます。

注：
　ネットワーク上の他ユーザが照会中の商品の入出庫データを追加・更新した場合、“画面更新”をクリックすると、最新の在庫情報が表示されます。

※操作方法
　計算するチェックボックス　―　チェックすると「FM計算方式」の在庫情報が表示されます。チェックを外すと在庫情報の計算を行わないので、画面表示が高速になります。

　尚、「FM計算方式」の出庫数計/入庫数計/在庫数のフィールドをレイアウト上に配置するだけで、システム起動後に初めて商品レイアウトを開く際に時間がかかります。
入出明細に170万件のレコードがある場合、当方の環境下では、1分前後の時間を要します。

　この詳しい理由については割愛しますが、簡単に言うと入出明細テーブルのビューに対して、DISTINCT句を含むクエリを発するためです。
「FM計算方式」が不要であればこれらの3フィールドはレイアウト上から削除して構いません。

　その他の在庫関連記事を読む

以上

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成

　前回の記事では、iPad のバーコード読み取りによる棚卸入力機能を実装するところまでをご紹介しました。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　棚卸作業をしてみると、システム上の在庫数と、棚卸在庫数（実在庫）が一致しない　―　誤差がでる ― ことはよくあることです。

FMEasy在庫 R1.0/R1.5 に在庫誤差調整伝票作成機能を実装する

　今回は『FMEasy在庫 R1.0/R1.5』をカスタマイズし、入庫/出庫の調整伝票を作成することにより在庫誤差調整を行う機能の作成方法をご説明します。

　前回と同様、以下の用語を使っていきます。

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

　それでは、こちらの動画をご覧いただいたあとで、実際のカスタマイズ方法をご紹介します。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 在庫誤差調整に必要なフィールドを準備

　以下のフィールドを EasyData15.fmp12（R1.0の場合、EasyData.fmp12） の商品テーブルに追加します。

　[c在庫誤差]（計算）　―　在庫誤差、誤差がある場合、調整の対象となる
　式：　If(棚卸在庫 = ""; 0; c在庫数 - 棚卸在庫)   //[棚卸在庫]が空欄(未入力)の場合、誤差は 無いものとみなす

　[c入庫数調整]（計算）　―　[c在庫誤差] がマイナスのときに、この誤差を入庫対象数とする
　式：　If(c在庫誤差  <  0; Abs(c在庫誤差); 0)

　[c出庫数調整]（計算）　―　[c在庫誤差] がプラスのときに、この誤差を出庫調整伝票の対象とする
　式：　If(c在庫誤差  > 0; c在庫誤差; 0)

　[gNo]（数値型、グローバル）　―　入庫伝票No/出庫伝票No の入出明細取込用一時記憶フィールド、後述のスクリプトで使用

2. 在庫誤差調整伝票作成スクリプトを作成

　このスクリプトの仕様は以下の通りです。

1)  在庫基準日を本日の日付（棚卸作業実施日）にする。
2)  棚卸作業を行わなかった商品は調整対象から除外する。
3) [在庫数] - [棚卸在庫] の誤差がプラスの場合は 出庫伝票、マイナスの場合は 入庫伝票 を作成する。
4) [在庫数] - [棚卸在庫] が 0 になる商品については、調整伝票を作成しない。
5) 入庫伝票/出庫伝票 の[伝票区分]は [7:在庫調整]（新設）とし、通常の伝票区分とは区別する。
6) 入出明細::備考フィールドに[棚卸担当ID]を記録。

　上記の条件に従ってスクリプトを記述すると、たとえばこのようになります。

　スクリプトの流れ上、入力チェックやウィンドウ切替などのステップも含まれていますが、基本的には上記の赤囲みの部分が押さえられていれば調整伝票を作成できるようになります。

① システム在庫を本日時点のものにする

　棚卸作業が終わった直後、つまり本日時点のシステム在庫と、棚卸在庫の差違をみるため、[在庫基準日1]　に本日の日付を設定します（Get(日付)）。

② [c入庫数調整] に値が入っている商品データを検索します。　
　このデータが入庫伝票作成対象となります。
　対象レコードがみつかった場合は、入庫伝票を新規作成し、その[入庫No]を [gNo]に一時記録します。

　次に、対象商品データを入庫明細として「入出明細」テーブルに取り込みます。
　その際、[入庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
仕入単価	→	仕入単価
JAN	→	JAN
棚卸担当ID	→	備考
c入庫数調整	→	入庫数量
gNo	→	入庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

③[c出庫数調整] に値が入っている商品データを検索します。　
　このデータが出庫伝票作成対象となります。
　対象レコードがみつかった場合は、出庫伝票を新規作成し、その[出庫No]を [gNo]に一時記録します。

　次に、対象商品データを出庫明細として「入出明細」テーブルに取り込みます。
　その際、[出庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
販売単価	→	販売単価
JAN	→	JAN
棚卸担当ID	→	備考
c出庫数調整	→	出庫数量
gNo	→	出庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

　ここまでできたら、一度スクリプトを実行してみましょう。
　調整伝票が作成されるとともに、商品の[在庫数]と[棚卸在庫]がぴったり一致していれば成功です。

【入庫調整伝票の例】

【出庫調整伝票の例】

【在庫の一致を確認（テスト段階）】

　何度かテスト実行して、問題がなければ、上記スクリプト内でコメントアウトされている[棚卸在庫]および[棚卸担当ID]の全置換クリアステップを有効にします。

　これにより、棚卸調整在庫が作成された後は、自動的に棚卸情報がクリアされますので、次回の棚卸作業時に[棚卸在庫]および[棚卸担当ID]フィールドがクリアされていないということがなくなります。

【在庫誤差調整伝票スクリプトの配置場所】

　在庫誤差調整伝票作成の実行ボタンは、ここでは商品一覧画面に配置してみます。
　赤囲みのところにご注目ください。
　[棚卸在庫]フィールドを[在庫数]フィールドの下に配置することで、調整伝票作成前に棚卸状況を確認できるようになっています。

　そして、“調整実行”ボタンをフッタ位置に配置し、ボタンクリックで調整伝票を一括作成することができます。

　“調整実行”ボタンについては、ユーザ権限による制御を追加するなど、誤操作防止策を検討してみてください。


【重要：在庫誤差調整伝票を作成するタイミング】

　システム在庫は常に変動しています。
　このため、棚卸作業開始～在庫誤差調整伝票作成完了までの間、一般ユーザによるシステムの使用や入出庫作業を禁止する必要があります。

　「禁止！」と言っているのにアクセスしてくる困ったちゃんがいる場合、FileMaker Server を停止し、サーバ上で本スクリプトを実行します。
　これにより、在庫の誤差がなくなることになります。

　なお、繰越処理（在庫や各種残高を繰り越す処理）を行っている場合、繰越処理の中に本スクリプトを組み込むのも Good！と思います。

　その他の在庫関連記事を読む

（亀）

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　今回は、iPadによる棚卸入力モジュールの開発方法をご紹介していきます。

FMEasy在庫 R1.0/R1.5 に棚卸入力モジュールを実装する

　ここでは弊社製品 FileMaker 在庫管理テンプレート『FMEasy在庫 IWP/WD R1.5』に沿って解説を進めていきますが、『FMEasy在庫 R1.0』を利用することもできます。

Q.　棚卸入力モジュールを使うと、倉庫の商品のバーコードを iPad で読み取って商品個数を入力するだけで、素早く、簡単に棚卸作業が進められるようになるの？

A.　（最初から期待を裏切ってしまうかもしれませんが）微妙です。
　皆様は棚卸作業の時、商品リストを印字して、倉庫に持っていき、一人が商品をカウントして読み上げ、もう一人が数量をリストに書き込む、というような作業をされいると思います。

　リスト上の商品が棚番でソートされているようであれば、カウントした商品数を素早くリストに書き込むことができ、リストに書き込んだ数値をExcelや在庫管理アプリに入力するというのも、立派なやり方と思います。

　ただ、棚番管理ができていない等の理由により、リスト紙ベースの棚卸がうまく機能していないようであれば、iPadなどの携帯端末による棚卸を検討されてはいかがでしょうか。　

　iPad/iPhoneによる バーコードスキャンは慣れが必要です。スキャンをすばやく実行できるようになれば、棚卸入力モジュールはかなり有望と思います（自画自賛＞＜）。

　それでは、以下の2つの機能に分けて、その作成方法をご説明していきます。

　1. iPad および FileMaker Go 13 のバーコード読み取り機能による棚卸入力モジュール
　2. 上記で入力した棚卸在庫数とシステム上の在庫数の誤差を修正する調整伝票作成機能

　　今回は 1. の棚卸入力モジュールにいて説明しますが、その前に少しだけ用語のご説明……

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

iPadによる棚卸モジュールを作成する

まずは、こちらの動画をご覧ください。



　倉庫の商品棚のバーコードを iPad で読み取り、各々の商品の個数をタッチパネルで入力している様子です。

　操作手順は以下のとおり。

1. 画面上部の［JAN］フィールドをタップしてカメラをアクティグにする
2. バーコードにフォーカス。フォーカスが合うと、iPadが勝手に商品を検索してくれて、［棚卸在庫］がアクティブに。
3. 値一覧（1～9）の数値をクリックするか、テンキーから実際の在庫数を入力。
   
   以下、1～3 を繰り返して、各商品の［棚卸在庫］を入力していきます。

　さて、ご覧のように、バーコードは棚に貼りつけておくと、素早くスキャンできると思います。

　この動画では、私が棚卸作業をしていますが、バーコード読み取り時にカメラのフォーカスを合わせたり、数値をスムーズに入力したりするには少々コツがいります。
　慣れればかなり速くスキャンができるようになると思います。

　商品をひとつひとつ手に取り商品上のバーコードをスキャンすることもできますので、どちらが御社に適しているのか、検討してみてください。

　それでは、この棚卸作業用の画面を開発してみましょう。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 取扱商品の JAN コードを商品マスタに登録

　社内の取扱商品の JAN コードを商品マスタに登録しておきます。
　商品マスタへのJAN コードフィールドの配置方法と登録のしかたについては、こちらの記事をご参照ください。

　iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ


2. 商品テーブルに棚卸作業用のフィールドを追加

　棚卸作業をするにあたり、以下のフィールドを EasyData15.fmp12/EasyData.fmp12 の商品テーブルに追加します。

　[棚卸担当ID]　（数値型） ―　棚卸担当の[社員ID]を入力するためのフィールド
　[棚卸在庫]（数値型） ― 倉庫棚の在庫数を入力するためのフィールド

3. JANコード検索用のフィールドを UI テーブルに追加

　棚卸用バーコードスキャン用のフィールドを EasyApp15.fmp12/EasyApp.fmp12 の UI テーブルにグローバルテキストフィールドとして追加します。

4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加


　以下の 3 つの TO を追加します。

　1) 社員_棚卸担当ID （社員テーブル）
　2) self_棚卸担当ID （商品テーブル） 任意
　3) self_商品ID（商品テーブル） 任意

1) [棚卸担当ID]と社員マスタのリレーション

　商品TOの[棚卸担当ID] と社員_棚卸担当ID TO の[社員ID]を関連付けます。

　2) 同じ[棚卸担当ID]が過去に棚卸処理をした商品を調べるためのリレーション

　商品 TO の [棚卸担当ID] と self_棚卸担当ID TO の [棚卸担当ID] どうしを関連づけます。

　これにより、ある担当者が過去に実行した棚卸実績を閲覧できるようになります。
　棚卸機能としては必須のリレーションではありませんが、棚卸作業もれや棚卸ミスをチェックできますので、用意しておくと便利でしょう。

　3) 棚卸実績の[商品ID]からその商品の情報に移動するためのリレーション

　上記で用意した self_棚卸担当ID TO の[商品ID] と self_商品ID TO の [商品ID] フィールドを関連づけます。

　これにより、棚卸実績の中からその商品情報に移動（照会）できるようになります。
　棚卸機能としては必須のリレーションではありませんが、棚卸作業時には、商品情報照会の操作性がアップしますので、用意しておくと便利でしょう。

5. 棚卸作業用のレイアウトを追加

　EasyApp15.fmp12/EasyApp.fmp12　のレイアウトモードで新規レイアウトを作成します。
　FileMaker Pro 13 では、下図のように視覚的にレイアウトを作成できます。

　このとき、表示するレコードは「商品」、レイアウト名は ipad 用の棚卸画面とわかる名前を指定しておきます。

　また、ここでは縦置きを前提にしたレイアウト選択を行っていますが、運用時に縦置きと横置きとでどちらが使い勝手が良くなるかを事前によく検討しておくと、後々のレイアウト調整の手間が省けます。

　あとは上記で用意した TO とリレーションを使って、[棚卸担当ID]、[棚卸在庫]、[gJAN] （スキャン用）などのフィールドを配置していきます。

　たとえば、レイアウトの加工例はこのようになります。
　最低限のユーザ入力が必要になるフィールドには赤囲みを付けておきますので、参考にしていただけると幸いです。

　図中、「タップでスキャン開始」となっているフィールドは UI TO の [gJAN] フィールドになります。
　操作では、このフィールドをタップした瞬間にバーコード読み取りモードに移り、iPad のカメラが起動させるようにします。


7. バーコード読取スクリプトを編集（または作成）

　iPad からバーコードを読み取るためのスクリプトを用意します。
　スクリプトの作成方法の詳細については、こちらの記事をご参照ください。

　iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

たとえば、バーコード読取スクリプトの編集例はこのようになります。

8. JAN コードによる商品呼出スクリプトを追加

　ユーザが UI の [gJAN] フィールドにスキャンした JAN コードを使って商品検索を行うスクリプトを作成します。

　たとえば、以下の図のようになります。

9. [gJAN] フィールドにスクリプトトリガを実装

　[gJAN] フィールドを iPad でタップした瞬間（OnObjectEnter） にバーコード読取が実行されるようにスクリプトトリガを設定します。

　また、[gJAN]へのバーコード読み取りが終了した瞬間(OnObjectSave) に JAN コード検索が実行されるようにスクリプトトリガを設定します。

　たとえば、以下のようになります。

　ここまでできたら、iPad に FileMaker Go 13 をインストールして、棚卸入力テストを行ってみてください。

　本記事の棚卸操作のような動きになれば成功です。

【棚卸実績を表示させる】

　ここでは、画面右の棚卸実績ポータルの作り方について解説します。
　ご覧のように、同じ棚卸担当者（例：土屋）が行った棚卸実績が一覧表示されていると、棚卸在庫数とチェック漏れの確認ができて便利ですね。

　棚卸実績表示用のリレーションシップの設定については、前述の「4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加」をご覧ください。


　ポータル指定の際に使うリレーションは「self_棚卸担当ID」となります。

　
　このリレーションの参照先が商品テーブルとなっていますので、[商品名]と[棚卸在庫]を配置しておけばよいでしょう。

　本稿では省略しますが、“照”ボタンをクリックすることによって、その行の商品の詳細情報を別ウィンドウで表示させたりすると、より使い勝手がよくなるでしょう。

　在庫誤差調整機能については、次回の記事でご紹介したいと思います。

　「iPadでバーコードスキャンして、棚卸表ができました！」というだけでは「で？」と突っ込まれそうなので、入力した［棚卸在庫］とシステム上の在庫数の誤差を調整伝票を発行して修正する機能もつくりました。
　続きはこちらの記事をご覧ください。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成 

　その他の在庫関連記事を読む

（亀）

『FMEasy在庫』 のバックエンドを MySQL に変える（１） ― 概要

　『FMEasy在庫 R1.0/R1.5』ではバックエンドに FileMakerデータベースを使用しています。
　本稿では、これを MySQL 5.1或は5.6に置き換える方法の概要を説明すします。なお、本稿は『FMEasy R1.5』に沿って解説を進めていきます。

はじめに

FileMaker によるアプリで、バックエンドを FileMaker から SQLデータベース（ESS、External SQL Source）に置き換えるとき、リレーションシップのウインドウで各TOをFileMakerテーブルからESSテーブルに貼り替えるわけですが、このときリレーション、レイアウト、スクリプトおよびびセキュリティ内のフィールド等が壊れてしまいます（詳細は後述）。
　この場合、壊れた設定をひとつひとつ手動で設定し直さなければならなくなります。実に無意味で苦痛な作業を強いられるわけですが、対策が記されたサイトがみつかりました。

FileMaker, mySQL, and ESS; A Little Known Secret, to Me Anyway

　上記を要約すると、ESSテーブルに貼り替える前に、「FileMakerのテーブルを作成日順でソートし、そのソート順にESSテーブルのフィールドを並び替えた後に、FileMakerのリレーションを張り替えろ」、というもの。
　小社でこの方法をやってみましたが、うまくいきませんでした（やはりフィールドのマッピングが壊れてしまう）。もし上記のリンクの方法で「旨くいったぜ」という方がいれば、一報頂ければ望外の喜びとなります。
　ということで、以下、無意味？で苦痛なバックエンドの変更手順を解説します。

開発環境

小社における開発環境は以下のとおり。


FileMaker Pro 12/13 Advanced
FileMaker Server 12/13 Advanced
MySQL 5.1/5.6
ODBC　5.1/5.2/5.3
MySQL Workbench 5.2/6.2

MySQL5.6で使用するODBCドライバは...
外部 SQL データソースに対してサポートされている ODBC ドライバ


注：
　FileMaker 12/13 による MySQL 5.5 の使用はビューが認識されない等の問題があるため、お勧めしません。

　MySQLの管理ツールはいろいろあります。あえてMySQLコマンドラインを使うならそれも良いですが、他にも以下のようなツールがあります。
で、どれがいいの、という議論は、
Workbench, Navicat, TOAD for MySQL?

　なお、MySQL Workbench 6.2 は 5.1/5.2 に比べるとかなり良くなってる印象です。

データベース及びテーブルを作成する

ツールが決まったらスキーマ（ここでは名称を easyinv15 とする）とテーブルを作成します。このとき、テーブル名とフィールド名は、『FMEasy在庫 R1.0/1.5』のデータ用ファイル EasyData15.fmp12 のテーブル/フィールド名と合致させるようにします。
　なお、計算フィールドについてはMysqlApp.fmp15 のシャドーテーブル（後述）で作成可能ですが、パフォーマンスが劣化するのでなるべく使用しないように設計します。また、グローバルフィールド（グローバル値を持つテキスト/数値/日付/タイムスタンプ/オブジェクトの各フィールド、ここでは計算フィールドを除く）はシャドウテーブル内では作成できないため、グローバルフィールドに関連する処理は再設計が必要となります。特に在庫関連機能の再設計は面倒なので、機会を改めて述べたいと思います。

さて、スキーマ/テーブルの作成が終了したら、右図のようにODBC設定を行います。

 

外部データソースの変更とリレーションキーの再設定

次にFileMaker側。まず、「FMEasy在庫 R1.5」の EasyApp15.fmp12 を複製して適当な名称を付けます（ここでは、MysqlApp.fmp12）。つぎのこのファイルを開きます。［ファイル］メニュー→［管理］→［外部データソース...］を選択し、下図のように設定します（名前は EasyODBC15 とする）。このとき、もともとあったFileMakerのデータソース EasyData15 は削除しておきます。

　つぎに「リレーションシップ」タグを開くと、元の EasyData15.fmp12 のテーブルによるリレーション設定は喪失して下記の図のようになっているので、個々のTOを上記で登録した EasyODBC15 のテーブルに正しく張り直します。
　この際、元の EasyApp15.fmp12のリレーションシップ画面またはその印字物を参考にします。

この時、TO名は元のママになるよう注意します。たとえば、「入出明細_入庫」TOを選択し直すと「入出明細」になってしまうので、張り直す直前にTO名をコピーし、張り直し後に「入出明細」になったらペーストして上書きすると良いでしょう。

　なお、この張り直し後に［テーブル］タブをクリックすると、今選択したMySQLのテーブルがイタリック（斜体）で表示されます。
　これらのテーブルは（MySQLの）シャドウテーブルと呼ばれます。このシャドウテーブル内では計算フィールドを作成することができますが、他のフィールドは作成できません。MySQLテーブルのフィールドを新設/変更/削除するには、MySQLコマンドライン等の他ツールを使用する必要があります。

レイアウトのフィールド張り替え

TOを張り替えてた時点で、レイアウト上のフィールドも誤ってマップされてしまうので、各レイアウトの各フィールドを一つ一つ、張り直す必要があります　―　絶望的に退屈だけど、間違えられない作業ですね。

TO張り替え後、壊れてしまった取引先レイアウト ― 一つ一つレイアウトを開き
不正なフィールドを一つ一つ張り替えていく

スクリプトはStandardのものを開いてコピペ

次はスクリプトです。MysqlApp.fmp12内のスクリプトに設定されているフィールド名もグチャグチャになっているので、元の「FMEasy在庫 IWP/WD R1.5」の正しいスクリプトをコピって、MysqlApp.fmp12側に貼ります。
　具体的には、MysqlApp.fmp12 とともに EasyApp15.fmp12を開き、双方のファイルの「スクリプトの管理」ウインドウを開きます。次に EasyApp15.fmp12 側のスクリプトを開いて中身をすべてコピーし（Cntrl＋A → Cntrl＋C）、対応する MysqlApp.fmp12 のスクリプトを開きペーストしていきます（Cntrl＋A → Deleteキー → Cntrl＋V）。

MysqlApp.fmp12 の壊れたスクリプト。フィールドに関するステップが壊れている。
MysqlApp.fmp12側で正しいスクリプトの中身をコピーし、上図でCntrl＋A をしてスクリプトの中身を選択、
Deleteキーで削除、Cntrl＋V で 正しいモノをペーストし直す。

 　これを壊れてしまったすべてのスクリプトに対して繰り返し実行します。

値一覧の修正

値一覧も修正が必要になります。下図で赤枠は壊れてしまったモノです。青枠はMySQLでは数値フィールドに文字列を入力することが許容されないため修正を要するモノで、これらのフィールドがスクリプトに使用されている場合は、数値のみをセットするようにスクリプトも修正する必要があります。

その他

　「FMEasy在庫」では不要ですが、他のシステムではアクセス権限セットやカスタム関数についても修正が必要になる可能性があります。



　以上、やっていて実に虚しくなる作業ではあり、もうすこしスマートな方法があるのではないかと。

　ということで、次回は在庫算出についてご紹介します。
　FileMakerのリレーションを使用して、「FMEasy在庫 R1.0/R1.5」のように、

　　　　前回繰越在庫＋SUM(今回入庫数)－SUM(今回出庫数)

　とかやってしまうと、FileMakerバックエンドより時間がずーっとかかってしまうので、方法と、高速なMySQLの実力を発揮できそうな方法の2つをご紹介したいと思います。

　その他の在庫関連記事を読む

（土屋）

受注・受注残管理モジュールを作る（４） 受注残の算出― FMEasy在庫のカスタマイズ

　本稿では商品毎の受注残、可用在庫等をどのように算出するかを説明します。

在庫情報タブ

商品レイアウト上にタブオブジェクトを配置します。在庫情報タブには在庫及び受注残関連フィールドを配置します。

商品テーブルに追加するフィールド

フィールド名	型	計算式	解説
繰越受注残	数字	―	繰越処理実行時に、各商品の［繰越日付］時点の［受注残］を記録。尚、繰越処理は未実装。
受注数	計算（数字）	Sum(受発注明細_商品::受注数量)	［在庫基準日］までの［受注数］計。［受注数］は受注画面上の［数量］または［受注数］
納品数	計算（数字）	Sum(入出明細_商品#納品数::出庫数量)	［在庫基準日］までの［納品数］計。［納品数］は受注画面上の“出庫移行”ボタンにより出庫登録された商品の数
受注残	計算（数字）	Case(IsEmpty(繰越情報::繰越日付) or  g在庫基準日1 < 繰越情報::繰越日付;0; 繰越受注残) -納品数+受注数	［在庫基準日］の受注残（受注はしたが納品していない商品の数）
可用在庫	計算（数字）	在庫数-受注残	販売先（用途）が決まっていない自由に使用できる商品の数
gcKey1	計算（数字）	1（常に1）	入出明細レコードが受注明細と紐付されているかチェックするためのシステムフィールド。

リレーション

　上図の入出明細_商品#納品数で「gKey1≦受注明細ID」が「真」であれば、その入出明細レコード（出庫した商品）は“出庫移行”ボタンにより受注画面から出庫登録されたことになります。
　逆に「gKey1≦受注明細ID」が偽であれば、その入出明細レコードに対する受注登録がないことになります。

在庫情報の変化

 さて、右図上の在庫状況において、受注画面上で［商品ID］＝1の商品明細の［移行数］に「10」を入力し“出庫移行”ボタンを実行する（右図中）と、在庫情報は右図下のように変化します。

　つまり、10 個の商品を出庫登録したのだから、［納品数］は10増えて「11」となり、［受注残］はその分減って「1」となります。

　このとき［出庫数］も 10 増えて「49」に、［在庫数］はその分減って「42」となります。






















以上

　その他の在庫関連記事を読む

（土屋）

受注・受注残管理モジュールを作る（３）受注残タブの実装― FMEasy在庫のカスタマイズ

　本稿では受注残管理モジュールを作成します。受注レイアウトには受注品目入力用の「受注」タブと、受注残管理用の「受注残」タブを配置します。

仕上がりイメージ

受注残関連仕様

下表は上図の受注残関連オブジェクトの仕様になります。

オブジェクト	タイプ	説明
伝票区分	数値FD	レコード確定時、1:全残(納品した商品無)、2:残有（受注残の商品有）、3:過納（過剰納品した商品有）、4:完納（受注した商品を全て納品）の何れかの値がセットされる。 OnRecordCommitを使用しスクリプトを起動。尚、本フィールドを計算フィールドにすることもできるが、索引が設定できずレコードが増えるに従い検索速度が劣化してしまう。
Id	数値FD （主キー）	「受発注明細」テーブルの主キー。“出庫移行”ボタン実行時、このキーの値を移行先のテーブルである「入出明細」テーブルの［受注明細ID］に貼り付け、納品数算出用のTO（入出明細_受注#注残）の外部キーとして使用。下表及び下のリレーション図参照。
受注数	数値	＝受注タブの［数量］
納品数	計算FD(数値)	当該商品の出庫への移行数合計、下表及び下のリレーション図参照。
受注残	計算FD(数値)	受注数－納品数、本値が0以外（受注残がある）の場合、本フィールドの背面が赤くなるように条件書式を設定すと、受注残がある商品が一目で解る。
移行数	数値FD	当該商品を出庫移行する数量をユーザが指定する。
→	ボタン	上記［受注残］を［移行数］に貼りつける。
出庫移行	ボタン	各商品を［移行数］分、出庫へ移行・登録する。

FD：フィールド

EasyData15.fmp12 のテーブル定義

名称	タイプ	補足
■受注テーブ
伝票区分	数値	上表参照
■受発注明細テーブル
ID	数値(主キー)	上表参照
納品計	計算(数値)	Sum(入出明細_受注#注残::出庫数量)、上表及び下表参照
受注残	計算(数値）	上表参照
移行数	数値	上表参照
■入出明細テーブル
受注明細ID	数値(外部キー)	上表及び下表参照

EasyData15.fmp のリレーション

受発注明細テーブルに、［納品数］=Sum(入出明細_受注#注残::出庫数量)、を作成

EasyApp15.fmpの出庫移行ボタンのスクリプト

出庫移行ボタンは［移行数］で指定した数量分の商品を出庫に移行します　―　つまり、受注画面で入力されたデータの一部を出庫（出庫/入出明細テーブル）にコピーします。ポータルを含むデータを他のテーブルにコピーする場合、1.元のデータを一旦変数に格納して変数をコピー先のテーブルに貼りつける方法と、2.元のデータを格納するテーブルからコピー先のテーブルへ取り込む方法、の2つがありますが、後者の方が高速になります。

　以下は後者の方法を用いたスクリプト例です。
（当スクリプトは検証不十分です。利用は自己責任でお願いします。　m( _ _ )m）

---

#
#事前チェック
#
スクリプト実行 [ 「gブラウズ以外実行不可-IwpWD」 ]
スクリプト実行 [ 「gレコード無CK-IwpWD」 ]
スクリプト実行 [ 「gレコード確定強制-IwpWD」 ]
#
#受注ヘッダ情報をUIのグローバルフィールドにセット（後でUIを取り込み、出庫ヘッダを作成する前処理）
#
フィールド設定 [ UI::gCompId; 受注::得意先ID ]
フィールド設定 [ UI::gDeptId; 受注::請求部署ID ]
フィールド設定 [ UI::gPicId; 受注::担当ID ]
フィールド設定 [ UI::gTaxRate; 受注::消費税率 ]
フィールド設定 [ UI::gDate; Get(日付) ]
変数を設定 [ $oriWinName; 値:Get ( ウインドウ名 ) //スクリプトの最後でこのウインドウに戻る為、記憶する ]
#
#移行する受注明細を抽出
#
関連レコードへ移動 [ テーブル: 「受発注明細_受注」; 使用するレイアウト: 「受注明細#取込」 (受発注明細_受注) ] [ 関連レコードのみを表示; 新規ウインドウ ]
変数を設定 [ $orderNo; 値:受注::受注No ]
検索実行 [ 指定された検索条件: レコードの検索; 条件: 受発注明細_受注::受注No: 「$orderNo」 AND 受発注明細_受注::移行数量: 「>-9999999999」 ] [ 記憶する ]
#
#UI→出庫取込
#
関連レコードへ移動 [ テーブル: 「出庫」; 使用するレイアウト: 「出庫」 (出庫) ] [ 関連レコードのみを表示 ]
レコードのインポート [ ソース: 「file:EasyApp15_p」; ターゲット: 「出庫」; 方法: 追加; 文字セット: 「シフト JIS」; フィールドデータのインポート順: ソースフィールド 37 のインポート 出庫::得意先ID ソースフィールド 38 のインポート 出庫::請求部署ID ソースフィールド 39 のインポート 出庫::担当ID ソースフィールド 40 のインポート 出庫::消費税率 ソースフィールド 41 のインポート 出庫::出庫日 ] [ ダイアログなし ]
変数を設定 [ $shipNo; 値:出庫::出庫No ]
#
#受注明細→出庫明細を取込
#
レイアウト切り替え [ 「出庫伝票」 (入出明細_出庫) ]
レコードのインポート [ ソース: 「file:EasyApp15_p」; ターゲット: 「入出明細_出庫」; 方法: 追加; 文字セット: 「シフト JIS」; フィールドデータのインポート順: ソースフィールド 2 のインポート 入出明細_出庫::商品ID ソースフィールド 3 のインポート 入出明細_出庫::販売単価 ソースフィールド 13 のインポート 入出明細_出庫::備考 ソースフィールド 14 のインポート 入出明細_出庫::単位 ソースフィールド 15 のインポート 入出明細_出庫::受注明細ID ソースフィールド 20 のインポート 入出明細_出庫::出庫数量 ] [ ダイアログなし ]
フィールド内容の全置換 [ 入出明細_出庫::出庫No; 計算で置き換える: $shipNo ] [ ダイアログなし ]
フィールド内容の全置換 [ 入出明細_出庫::入出庫日; 計算で置き換える: Get(日付) ] [ ダイアログなし ]
関連レコードへ移動 [ テーブル: 「出庫」; 使用するレイアウト: 「出庫」 (出庫) ] [ 関連レコードのみを表示 ]
ウインドウの調整 [ 収まるようにサイズ変更 ]
ウインドウを選択 [ 名前: $oriWinName; 現在のファイル ]
フィールドへ移動 [ 受発注明細_受注::移行数量 ]
#
#移行数FDはクリアしておく
#
Loop
　　Exit Loop If [ 受発注明細_受注::Id = "" ]
　　フィールド設定 [ 受発注明細_受注::移行数量; "" ]
　　ポータル内の行へ移動 [ 次の; 最後まできたら終了 ]
End Loop
レコード/検索条件確定 [ ダイアログなし ]

---

以上

　その他の在庫関連記事を読む

（土屋）