ラベル FMEasy在庫 の投稿を表示しています。 すべての投稿を表示
ラベル FMEasy在庫 の投稿を表示しています。 すべての投稿を表示

2014-11-25

『FMEasy在庫』 のバックエンドを MySQL に変える(1) ― 概要


 『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つをご紹介したいと思います。




(土屋)

2014-11-01

受注・受注残管理モジュールを作る(4) 受注残の算出― 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」となります。






















以上


(土屋)

2014-10-23

受注・受注残管理モジュールを作る(3)受注残タブの実装― 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
レコード/検索条件確定 [ ダイアログなし ]


以上


(土屋)

2014-10-08

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

FileMaker Go 13 を使ったバーコード読み取り機能について

 FileMaker Go 13 にはバーコード読み取り機能が付属しています。
 専用のバーコードリーダーをお持ちであれば、もともとデスクトップからバーコード入力できますが、バーコードリーダーをお持ちでなくても、iPhone や iPad のカメラ機能でバーコードを読み取れるようになったのは嬉しいですね。



 外回りが多い営業さんや、倉庫管理をする際にも、モバイル操作でバーコード読み取りができれば、適用範囲も広がりそうです。

 今回は、弊社製品『FMEasy在庫』をカスタマイズすることによって、iPad から商品バーコード(JAN)を読み取りながら、入庫登録ができるようにする方法をご紹介します。


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

【用意するもの】
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. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。細心の注意を払い、ご自身の責任で行ってください。

『FMEasy在庫』に JAN 読み取り機能を追加する

 今回は、『FMEasy在庫 IWP/WD R1.5』を使って説明を進めていきますが、『FMEasy在庫 R1.0』開発版をご利用の方も、操作は同様となります。

1. 商品レイアウトに [JAN] フィールドを配置

 『FMEasy 在庫』には、[JAN] という名前の予備フィールドがあらかじめ用意されていますので、FileMaker Pro 12/13 を起動して開発者パスワードで EasyApp15.fmp12/EasyApp.fmp12 を開き、下図のように、お好みの位置に [JAN] フィールドを配置してください。



2. iPad からのJAN コード読み取り機能を商品レイアウトに追加


 iPad からから上図の[JAN]フィールドをタップしたときに、バーコード読み取り機能が走るようにします。

 スクリプトエディタを開き、「デバイスから挿入」スクリプトステップを使って[JAN]フィールドにバーコードが挿入されるように指定します。




 このとき、FileMaker Go で [JAN] フィールドをタップしたときのみ、このスクリプトが実行されるようにしますので、一行目の If 文に PatternCount(Get ( アプリケーションバージョン ); "Go") が指定されているところに注目してください。

 バーコードの読み取りが終わったら、次のフィールドに移動するように設計しておくと、システム運用時に使いやすくなるでしょう。

 これをスクリプトトリガとして、商品画面の [JAN] フィールドに設定します。
 イベント発生のタイミングは、OnObjectEnter (タップ時)になります。



 ここまでできたらレイアウトを保存します。

 FileMaker Go 13 で商品レコードにアクセスし、[JAN] フィールドをタップするとカメラに切り替わりますので、JAN のバーコードを読み取ると、JAN コードが登録されます。



 同じ要領で、JAN コードを商品マスタに登録していきましょう。



3. 入出明細テーブルに [JAN] フィールドを追加

 EasyData15.fmp12/EasyData.fmp12 のフィールド定義を開き、入出明細テーブルに [JAN] フィールドをテキスト型で追加します。



4. 入出明細の [JAN] から商品マスタの [商品ID]を呼び出すためのリレーションを追加

 EasyApp15.fmp12/EasyApp.fmp12 のリレーション定義を開き、「入庫レイアウト TOG」のセクションに下図のようにリレーションを追加します。

 入庫_商品#JAN TO の参照テーブルは商品テーブルです。
 商品と入出明細の [JAN] を関連づけます。



5. iPad 用の入庫管理レイアウトを作る

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

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

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



 レイアウトのテーマや体裁はお好みで結構ですが、明細部分に [入出明細_入庫::JAN] フィールドを配置するのを忘れないようにしてください。

 たとえば、できあがったレイアウトを FileMaker Go 13 で閲覧してみると、以下のようになります。


 上図のように、[商品ID]と[JAN]フィールドは両方配置してください。

6. [JAN] のバーコード読み取りスクリプトを作り、OnObjectEnter のスクリプトトリガとして動作させる

 前述「2. iPad からのJAN コード読み取り機能を商品レイアウトに追加」と同じ操作になりますので、ここでは説明を省略します。
 
7. [商品ID]/[JAN] 相互呼び出しのスクリプトトリガを追加する

 iPad入庫画面で、[商品ID] を入力したら [JAN] を自動的に呼び出し、また[JAN]を入力したら [商品ID]を自動的に呼び出すようにスクリプトを作成します。

 『FMEasy在庫』のような分離モデルを採用したシステムの場合、レコード未確定状態ではフィールド定義のルックアップが正常に動作しないことがありますので、このスクリプトを考慮されるとよいでしょう。

備考: [仕入単価]、[単位]の呼び出しも用意しておくとより確実でしょう。



 スクリプトができたら、iPad入庫画面の [商品ID] と [JAN] のそれぞれに、OnObjectSave のタイミングでスクリプトトリガを設定します。



 これで準備が整いました。


 以降はデモビデオで実際の操作感をご覧ください。

『FMEasy在庫』に iPad から入庫登録をするデモ動画

商品を仕入れたという前提で、iPad入庫画面で商品のバーコードを読み取って JAN コードを入力しているところです。

 

 JAN コードの入力のタイミングで、[商品ID] が自動入力されます。
[数量]を入力すると、制御が次の行に移ることによって[JAN] 読み取りのスタンバイ状態になりますので、連続的な操作でバーコード読み取りができます。


 実際にやってみてわかったことですが、カメラ機能のフォーカスを合せるのに少々コツがいります。
 今回は手ブレ対策として、このように鉄アレイで本体を固定してバーコード読み取りをしました。



補足:
 このような iPad スタンドを使ってみると作業しやすくなるかもしれません。
 鉄アレイに比べれば見た目もグーーーンとおシャレですし、何と言っても角度を変えられますから^^。



※『FMEasy在庫』をカスタマイズするには、開発版が必要となります。


参考記事:
FileMaker Go による iPad/iPhone 向けソリューションの開発ヒント集


『FMEasy在庫』カスタマイズ関連記事:
受注・受注残管理モジュールを作る ― FMEasy在庫のカスタマイズ (1)
受注・受注残管理モジュールを作る ― FMEasy在庫のカスタマイズ (2)



2014-07-27

受注・受注残管理モジュールを作る(2)テーブル、リレーション、レイアウトの設計 ― FMEasy在庫のカスタマイズ

 受注残は面倒なので脇に置いておき、まず受注モジュールを作ります。
 作業にあたり、カスタマイズする『FMEasy在庫 R1.0/R1.5』は分離モデル(注)を採用しているため、作業するファイルが2つ ― EasyApp15.fmp12とEasyData15.fmp12 ― あることに注意してください。

 EasyData15.fmp12 は業務データ用のファイルで、原則として業務用テーブルに加え、業務用テーブルの計算フィールドに使用する最小限のリレーションを含みます。
 EasyApp15.fmp12 はアプリケーション/システム用のファイルで業務用テーブルは含まず、アプリ用のテーブルとリレーション、レイアウト(画面や帳票)、さらに業務ロジックを組み込んだスクリプトを含んでいます。

 作業に際しては、このことを念頭に混乱のないよう作業を進めてください。

注:『FMEasy在庫 R1.0/R1.5』は テンプレートですので、データファイルとアプリファイルの分離度は高くなっていません。
 分離度を高めるためには、データファイル(EasyData.fmp12)では計算フィールドやフィールド制御は極力行わないように設計します。

受注モジュールのテーブル、リレーション、レイアウト、スクリプトを作る

 受注モジュールは出庫モジュールと類似していますので、出庫関連のテーブル、リレーション、レイアウト、 スクリプトをある時はコピー・変更し、あるときは直接変更し、またあるときは変更することなく共用します。

 『FMEasy在庫 R1.0/R1.5』は、最小限の労力で他の類似モジュールを追加できるよう設計しています。

EasyData15でテーブル/フィールドを作成・定義する

 まずはテーブルから作成します。EasyData12.fmp12の出庫/入出明細テーブルを下図のように選択し、コピペし、それぞれの名称を「受注」と「受発注明細」に変更します。

 入出明細テーブルは、出庫明細と入庫明細の共用テーブルであるため、今後発注モジュールに対応することを想定して「受発注明細」という名称にしておきます。

※本稿では原則として発注には触れませんが、発注関連モジュールも開発する場合、発注関連のテーブル/リレーション/スクリプトも作成しておく方が効率的です。

図1.出庫、および入出明細テーブルをコピー&ペーストして、受注、および受注明細テーブルを作る

 2テーブルの名称を変更したら、その中のフィールド名を変更(図3/4)。

注:
  • フィールド名は後述の図3と図4に準じること(変に変更すると、スクリプトの変更が大変になる)
  • フィールドの変更・削除は極力しない→動作しなくなる
  • 入庫関係のフィールド名は、発注モジュールを作成する場合に備えそれらしく変更しておく(入庫No→発注No)
なお、受注用のリレーションが無いと設定できない計算フィールドは、下記のリレーションシップを設定後に定義します。

EasyData15でリレーションシップを作成する

 EasyData15.fmp12 のリレーションシップは出庫TOG(Table Occurence Group)をコピペし、出庫TOGに準じて下図のオレンジのTOG のように設定します。
なお、、リレーションシップも複数選択してペーストができます。

図2.出庫レイアウトTOG をコピー&ペーストして受注レイアウトTOGをつくる

 リレーションシップを正しく設定すると、<不明>あるいは<フィールドが見つかりません>と表示されていた計算フィールドを定義できるようになりますので、これも出庫/入出明細の計算フィールドに準じて定義していきます。

図3.リレーションシップを設定後、受発注明細テーブルのフィールドを再定義

図4.リレーションシップを設定後、受注テーブルのフィールドを再定義

EasyApp15でリレーションシップを作成する

 EasyApp15.fmp12 のリレーションシップも出庫TOG(Table Occurence Group)をコピペし、出庫TOGに準じて下図のように受注レイアウトTOGを設定します。

 赤枠の部分の「得意先List」と「出庫商品List」はUIテーブルとのリレーションシップであるため各レイアウトから共用できるので、受注側での作成は不要となります。
 また、濃い青の3つのTO(Table Occurence)はIWP(インスタント)専用であるため今回は作成しませんが、受注モジュールをIWPに対応させる方は作成する必要があります。

 なお、TOの名称は下図に準じるようにしてください(変な名称を付けると、スクリプトの変更が大変になってしまいます)。


レイアウト/値一覧を作成する

 受注用レイアウトは EasyApp15 側でのみ作成します。出庫レイアウトをレイアウトモードで表示し、[レイアウト]―[レイアウト複製]を選択します(一種のコピペ)。
図の赤枠内のように、レイアウト名を「出庫のコピー」から「受注」に、レイアウトテーブルを「出庫」から「受注」に変更します。


 この段階ではフィールド/ポータルは出庫または入出明細のものが貼られているので、フィールドをダブルクリックしながら、受注/受注明細関連のものになるように変更していきます。
 また、出庫No/出庫日、出庫などのレーベル名も適当なものに変更しましょう。また、変更漏れがないように注意するようにしてください。

 値一覧は、伝票区分、担当ID、得意先ID、商品ID、請求部署ID、数量、単位の各フィールドで使用されているが、変更する必要があるのは、伝票区分と請求部署IDに割り当てられているもののみ。

 ここまで、慣れている人であれば1~2時間でできると思われますが、次のスクリプトからがかなり作業が複雑になってきます。

注:
 受注一覧、受注伝票の各レイアウトも実務では必要になると思われるので、前者については出庫一覧レイアウトを、後者については入庫伝票レイアウトを上記の要領でコピーして作成してください。

スクリプトを変更する

 さて、出庫レイアウトをコピーして作った受注レイアウトは以下のようになります。
 ボタンに割り振られたスクリプトだけではなく、フィールド/レイアウト等に割り振られたスクリプト(赤枠部)もひとひとつ変更が必要かどうか吟味し、必要があれば変更を加えていきます。

 スクリプト変更はかなり骨が折れる作業で、下手に変更を加えると他のモジュールに障害を与えることがあるので慎重に作業してください。 変更後のテストも十分に行う必要があります。



 下表はスクリプトが割り振られたオブジェクトの一覧です。
 チェックマークが付いてるものは変更が必要になります。
*1 『FMEasy在庫 IWP/WD R1.5』でのみ利用可。変更難度高し。“選”ボタンを受注対応させない場合、レイアウトから削除すること。


以上

 
(土屋)

2014-07-18

受注・受注残管理モジュールを作る(1)概要と開発方針― FMEasy在庫のカスタマイズ

 弊社に寄せられる各種問い合わせで多いのがモジュールの追加 ― 「売上入金残管理モジュールを作りたい」、「受注残管理をしたい」といったものです。
 これらの質問はあまりにカバーする範囲が広く、また漠然としているので、回答も漠然としたものになります。

 そこで今回から数回にわたり、『FMEasy在庫 R1.0/R1.5』をカスタマイズし、受注・受注残管理モジュールを付加する方法の概要ご説明したいと思います。 

機能概要

  • 受注管理
  • 入力支援機能(FMEasy在庫 IWP/WD R1.5 のみ)
  • 受注伝票毎及び得意先毎の受注残管理 
  • 受注明細レベルで分納に対応する


用語

  • 在庫 ― 商品の入庫数計-出庫数計
  • 受注残 ― 商品の受注数計-出庫数計
  • 可用在庫 ― 在庫-受注残


注:
 弊社では商品の[在庫]から[受注残]を差し引いた値を[可用在庫]と呼んでいます。意味としては、倉庫に物理的に存在するだけではなく、買い手が決まっておらず(受注残となっていない)、得意先から注文があればすぐに出庫できる状態にある在庫です。
 逆に、倉庫に物理的に存在していても、買い手が決まっていて何らかの事情により倉庫に留め置かれている在庫は、出庫不能な在庫(非可用在庫)となります。


画面イメージと移植する機能

 弊社が2004年6月にリリースした「FlexManager R1.5」という製品の受注・受注残モジュールの一部を『FMEasy在庫』に移植します。下図はそのオールド製品の画面です。


【受注】

受注画面
 受注情報を入れる画面。この画面から必要最低限の機能を『FMEasy在庫』に移植します。


【受注残管理】
受注残管理画面

 受注残管理画面。受注残管理だけではなく、受注情報を利用した発注処理、その発注に対する入荷情報の表示(画面の[発注数(内入荷)])にも対応していますが、今回は発注・発注残管理機能には触れません。この画面から、受注残管理の必要最低限の機能を『FMEasy在庫』に移植していきます。


【分納管理】

分納管理画面

 受注商品データを売上に移行するための画面。新規に売上伝票を作成して(“新”ボタンを使用)そこへ受注データを移行することも、既存の売上伝票([売上No]をプルダウンメニューから指定)の売上明細に受注データを付加することもできます。なお、『FMEasy在庫』では売上モジュールはなく、代わりに出庫モジュールへ移行することになります。

開発方針

 「FlexManager 1.5」は結構機能がテンコ盛なので、複雑になりすぎないよう、受注残管理に焦点をあてて、必要最低限の機能を移植したいと思います。 (次回へ続く)



(土屋)

2014-06-30

インスタント Web/WebDirect対応在庫管理テンプレート『FMEasy在庫 IWP/WD R1.5』を本日リリース

 本日、『FMEasy在庫 IWP/WD R1.5』(フリー版)のダウンロードと販売を開始。


 ホントは昨年末にインスタントWeb(IWP)に対応の「FMEasy在庫 IWP R1.5」としてリリースする予定が、同時期に IWP の後継WebDirect(WD)を含む FileMaker Pro 13 がリリースされ、「タイミング、悪!ヽ(`Д´)ノ」、 と思いつつ、「WDにも対応させよう」と思い直し、艱難辛苦の末、今日を迎えることができました\( ̄▽ ̄;)/。


 以下、 本製品についての若干のご説明。


製品概要


  『FMEasy在庫 R1.0』 に検索・入力支援機能を付加し、インスタントWebとWebDirectに対応させたのが本製品です。


製品種類

  • フリー版(無料) ― データ入力無制限
  • 開発版(価格:¥54,000、税込) ― FileMaker Pro 12/13 Advancedにより開発可

 本製品リリース後も、在庫管理テンプレート『FMEasy在庫 R1.0』(フリー版/開発版 ¥26,250)は引き続きダウンロード/購入可。

開発方針


こんな感じで開発してみました。

  1. インスタントWeb(IWP)/WebDirect(WD)の両方に対応させる
  2. 入出庫・在庫の基本機能は『FMEasy在庫 R1.0』をそのまま踏襲
  3. FileMaker/IWP/WD間で、できるだけレイアウトを共有する(下記※参照)
  4. 検索・入力支援機能 ― 取引先または商品のレコードが千~1万件を超す場合、FileMaker標準の 関連フィールドによる値一覧は実用に耐えない(特にWeb環境下) ― ので、検索・入力支援機能を搭載する(後述)
  5. 検索・入力支援機能の流用性 ― 本製品をカスタマイズして売上/入金/仕入/支払/受注/発注等々の機能を付加する場合、取引先、得意先、仕入先、商品の入力が必要となるが、その時に検索・入力支援機能を簡単に流用できるように設計する
  6. 検索・入力支援機能は FileMaker/IWP/WD の3プラットフォームで利用できること
  7. WDの実行速度を落とさないように、レイアウトテーマは前版「FMEasy在庫 R1.0」の「レトロ」から「クラッシック」に変更 ― この為、本製品R1.5と前版R1.0の画面がかなり異なっている

※レイアウト共有で工数減?

 レイアウトを共有するとレイアウトだけでなくスクリプトも共有できる可能性が高まり、工数削減につながりそうだが、レイアウトを弄る度にFileMaker/IWP/WD、3つのプラットフォームでレイアウトのズレを気にしなければならなくなり、実際の工数減に繋がるかは微妙です。
 おおざっぱな方 ― 多少、オブジェクトが被ったりズレたりしても気にしない人はレイアウト共有し、細かいことが気になる人はレイアウトを分けた方が幸せかもしれないです。

 それともかく、本製品はIWPの入力更新系画面を除き、できるかぎり3プラットフォーム間でレイアウトを共有しています。

検索・入力支援機能


本製品のキモはなんと言っても検索・入力支援機能。
下図はWebDirect環境のChromeの画面。

[取引先の検索・入力支援機能]

※取引先画面で検索支援機能を使う
“検索支援”クリック検索支援画面が開く→取引先名を入力して“表示”表示された一覧から目的とする取引先を選択クリック元の取引先画面に戻り選択した取引先が表示される。

※出庫/入力画面で入力支援機能を使う
“選”クリック入力支援画面が開く得意先または仕入先名を入力して“表示”表示された一覧から目的とする得意先/仕入先を選択クリック元の出庫/入庫画面に戻り選択した得意先/仕入先が入力される

注:実行元の画面により、検索・入力支援画面に表示されるボタン、表記、機能が若干異なります。



[商品の検索・入力支援機能]

※商品画面で検索支援機能を使う
“検索支援”クリック検索支援画面が開く商品名を入力して“表示”表示された一覧から目的とする商品を選択クリック元の商品画面に戻り選択した商品が表示される

※出庫/入力画面で入力支援機能を使う
明細の“選”クリック入力支援画面が開く商品名を入力して“表示”表示された一覧から目的とする商品を選択クリック元の出庫/入庫画面に戻り選択した商品が入力される
  • 実行元の画面により、検索・入力支援画面に表示されるボタン、表記、機能が若干異なります。
  • 入力支援画面で[伝票単価][数量]を入力すると、その値が入出庫明細の単価と数量に入力されます。



Blog連動


 いくつかの問題もあります。 例えば、インスタントWeb(IWP)/WebDirect(WD)では満足な印刷ができない。これは FileMaker Serverの問題ですが、回避策がないこともないです。
 それは、ネットワーク上に印刷専用の FileMaker クライアント(FileMaker Robot)を常に起動しておき、IWP/WDクライアント(ブラウザ)から印刷リクエストがないか常に監視し、リクエストがあればFileMaker Robotから印刷を行うようにスクリプトを作成し、そのスクリプトを常に実行した状態にしておきます。

 別の問題として、IWPではダイアログボックス表示のスクリプトステップが使用できないため、レコード削除実行時に確認のダイアログが表示されずに即刻レコードが削除されてしまう、ということがある。

 また、 WDは各種ブラウザとの互換性が低いがFileMaker クライアントの再現性が高いのでインストラネットで、IWPは各種ブラウザとの互換性が高いので不特定多数対象のインターネットで使用したいが、WD/IWPの同時使用は可能か…等。 こうした問題・課題について、できるだけ本Blogで取り上げていきたいです。


サポート

前版インシデント2→今版5インシデント(365日間有効)に!

 ご質問については、Blog 記事として回答させて頂くこともあります →例1とか例2とか。


講習とか


 本製品をベースに在庫管理を学んでみたいという方はこんなのとか、IWPをやってみたいという方はこんなのとか、WDとはなんぞやという方はこれとか、あります。

 それでは足りない!、開発支援とかコンサルティングを!という方はこちら

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

(土屋)

2014-06-24

『FMEasy在庫 IWP/WD R1.5』 のクライアント強制フィールドの使用


『FMEasy在庫 IWP/WD R1.5』のユーザの方へ

 『FMEasy在庫 IWP/WD R1.5』はFileMakerクライアント、インスタントWeb(IWP)、WebDirect(WD)の3つのプラットフォームで動作する在庫管理テンプレートですが、本製品のMain Menu画面には[クライアント強制]というフィールドがあり、クリックすると「0:FM、1:IWP、2:WebDirect」のいずれかの値を選択することができます。 


本製品は「0:FM」が選択されていればPC上のFileMakerクライアントとして、「1:IWP」ならインスタントWeb環境に接続されているブラウザとして、「2:WebDirect」であればWebDirect環境に接続されているブラウザとして、実際のプラットフォームとは関係なく、動作します。 

 たとえば、PC上の FileMaker Pro 13 を使用し、『FMEasy在庫 IWP/WD R1.5』にアクセスする場合、デフォルトでは上記フィールドの値は「0:FM」が選択されています。 この時、“取引先へ”をクリックすれば、FileMakerクラインアント用に用意された以下の画面が表示され、これが本来の正しい動作です。

では、 上記のMain Menu画面の[クライアント強制]を「1:IWP」に変更して“取引先へ”をクリックするとどうなるでしょうか? その場合、インスタントWeb(IWP)用に用意された下記の画面が表示されます。


つまり、実行環境はFileMaker Pro 13であるにも関わらず、インスタントWebにアクセスしているブラウザの動作をシミュレートできます。 これは、主としてIWPアプリの開発時、デバッグ環境が存在しないため、FileMaker Pro Advanced にブラウザを動作をシミュレートさせ、デバッガに利用するための仕組みです。 よって、開発時以外は、[クライアント強制]の値は変更しないようにしてください。

注:
  • 本機能は他のプラットフォームをある程度はシミュレートしますが、プラットフォーム間でサポートするスクリプトステップや機能が異なる為、完全にシミュレートするものではありません。
  • 開発時のFileMakerクライアント上での「1:IWP」指定(IWPブラウザのシミュレート)と「2:WebDirect」指定(WebDirectシミュレート)を前提としています。その他の指定はお勧めできません。
以上


【関連リンク】
FMEasy在庫のカスタマイズ関連記事リスト