2014-11-26

『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) ―― 在庫誤差調整伝票の作成 


(亀)

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」となります。






















以上


(土屋)