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

2017-11-05

iBeacon の適用モデルを考える 3 ― 定位置ビーコン監視モデル(2)

 前稿では、iOS と FileMaker Go を使用して定位置にあるビーコンを監視する方法について記しました。この方法は簡単でとても導入しやすいのですが、ビーコンを監視する端末が多数となる場合、iPad や FileMaker の費用負担がのしかかってきます。また、数十台から百台を超える端末を管理するとしたら、iPad/iPhoneでは大変でしょう。 そこで小社では、FileMaker Go に依存せず、様々なプラットフォームで利用可能なビーコン情報収集サブシステム(以下、TpcBScan.js)を作りました。

多様なデバイスで動作する TpcBScan.js  

TpcBScan.jsは node.js、express.js、nobe.js等の node.jsファミリー群の環境下で稼働する ビーコン情報収集サブシステムで、Windows、Macintosh、iOS、Android、Linux 等をOSとするデバイスで動作します*1。デバイスはBLE対応である必要があり、BLEアダプタ未搭載の場合、BLEアダプタ(ドングル)が必要となります。
 その機能は FileMaker の RangeBeacons関数に準じますが、http リクエストに対して戻り値を返します。 戻り値にはRangeBeacons形式とJSON形式を指定できます。Macintosh/Windows の FileMaker から TpcBScan.js を利用する場合は、「URLから挿入」スクリプトステップを使用します。

*1 Windows (WebDirectを含む)、Maintosh、iPad、Linux (Raspbian) で動作することを確認しています


「FMEasy在庫 IWP/WD R1.5(開発版)」のユーザの皆様には、TpcBScan.js β版 をダウンロード頂けます。詳しくはこちらをご参照ください。(2017/11/8更新)

Raspberry Pi をビーコン監視端末にする

今回、ビーコン監視を行う端末には、安定性、廉価性、保守性に優れるRaspberry Pi(BLE と LANに対応する機種)を使用することにしましたが、BLE/LANであれば Raspberry 以外のデバイスでも構いません。

 システムを構築するにあたっては、各種処理をサーバを中心に行わせる方法と、 端末を中心に実行させる方法の2種類が想定されます。

左がWi-Fi/BLE付の Raspberry Pi Zero W(¥3,000位)、右が Wi-Fi/BLEアダプタを取り付けた Pi Zero(無印)


端末駆動型システム構成

2種類の方法の1つが「端末駆動型」(下図)で、Raspberry端末がビーコン管理に必要な情報(端末が担当するビーコンのUUID/Major/Minorのリストや 、テーブルに保存されている存否情報のリスト=ManagedBeaconsList)をアプリケーションサーバを経由しデータベースサーバから取得します。端末は担当するビーコンが発信する情報(ActiveBeaconsList)を TpcBScan.js を使用して取得します。端末は取得した ManagedBeaconsList と ActiveBeaconsList を比較し、差異があれば アプリケーションサーバに対してデータベース更新等のリクエストを行います。差異が全くない場合は、サーバに更新リクエストは行いません。端末が多くの処理を行うのに対し、アプリケーションサーバの処理はレコードの送信と更新に限られます。 この端末駆動型は端末数やビーコン数が多くサーバ負荷を軽減したい場合に有効なシステム構成と思われます。


図1

サーバ駆動型システム構成

もう一つの方法が下図のサーバ駆動型で、この場合、Rapberry 端末はサーバからのリクエストに応じて自身が担当するビーコンの情報(ActiveBeaconsList)をサーバに返すのみです。一方サーバは、上述の「監視端末駆動型」で端末が担った ActiveBeaconsList 作成処理以外の全てを行うことになります。サーバは各端末に順繰りにリクエストを送り、戻り値を処理していくため、端末が増えると「監視端末駆動型」に比べてサーバの負荷はグッと増えます。この構成は監視端末の数が少なく、サーバが過負荷にならない場合に有効なシステム構成と思われます。
図2

サーバ駆動型を FileMaker Server でやってみる

実は当初、「端末駆動型」システムでも「サーバ駆動型」システムでも、Raspberry(Linux) を使うのであれば、node.js/JavaScript や PHP 等によるWebプログラミングは必須だと思いこんでいたのですが、下図の構成であれば、FileMaker による開発のみで、「サーバ駆動型」を実現できることに気づきました。というのは FileMaker スクリプトには、「URLから挿入」と言うスクリプトステップがあり、このステップは FileMaker Server から実行できるからです。具体的には FileMaker Server から この「URLから挿入」を使用して、各 Raspberry 端末上の node.js に対して、ビーコン情報を返すように http リクエストを送ります。あとは「サーバ駆動型システム構成」で書いたように、FileMaker Server がすべての処理を行います。

図3

 ということで、小社では上図のシステム構成に基づき、多端末対応のFileMaker プロトタイプを作成し、4つの Raspberry と1つのWindows ― 計5台のビーコン監視端末を使用してテストを行いました。本来であれば500台程ビーコンを用意して、各端末に100台ずつビーコンを割り当ててテストしたいところですが、手持ちのビーコンが21台しかないため、各端末が同じ21台のビーコンを監視するように設定しています。

 下図が今回のテストで FileMaker で作成したプロトタイプの画面です。監視端末があるビーコンの情報を受信しない場合は当該ビーコンの[存否]フィールドに「×」が、受信した場合は「OK」が入力されます。


図4 FMPから“Multi-term. TpcBScan”を実行すると、後述のサーバサイドスクリプトが実行される

英語版の動画




 実際にFileMaker からサーバサイドのビーコン監視スクリプトを実行した時の FileMaker Server Console 画面が以下です。通常、[クライアント]にはコンピュータ名が表示されるのですが、サーバサイドスクリプトを実行している場合は、実行されているスクリプト名が表示されるます。 赤枠部がサーバから実行されているスクリプトで、このスクリプト([srv]subTpcB監視~)が5台の端末に対して ActiveBeaconsList (ビーコンから受信した情報)を FileMaker Server に送信するようにリクエストし、それを受信すると ManagedBeaconsList と比較して、必要に応じてデータベースの更新や、メール/SMSの送信等の必要な処理を行います。本「定位置監視ビーコンモデル」は継続してビーコンを監視し続けるモデルですので、赤枠部の各スクリプトは中止命令を受けるまで、常駐して処理を続けます。


図5

 さて、当初の予想ではこのシステム構成は サーバに大きな負荷がかかると思っていたのですが、実際にCPUのパフォーマンス(下図)を見てみると、予想ほどの負荷はかからないようです。
 FileMaker Server 16 は理論上は無制限(検証値的には500)の接続が可能ですので、理論上は無制限のビーコン監視端末を管理できます。

図6

SQL データベースの利用

前項では、FileMaker Server (FMS)は、ビーコン情報を取得し、ビーコンの存否を判断し、データベースを更新するというアプリケーションサーバとデータベースサーバの2つの機能を兼ねています。 一方、図3右下の点線部のように、ODBC対応のデータベースサーバ(以下、SQL DB)を利用する場合は、FMS をアプリケーションサーバとして使用することも可能と思われます。この場合、FMS は SQL DB に対する CRUD を担うことになりますが、CRUD には FileMaker の ESS と サーバサイドからの「SQL を実行」が使えます。以前、 FMS をSQL DB の帳票作成サーバとして使うという記事を書きましたが、FMSをアプリケーションサーバとして使用すると、いろんなことが簡単にできる可能性が広がると思います。


以上


(土屋)



関連リンク

2017-10-17

iBeacon の適用モデルを考える 2 ― 定位置ビーコン監視モデル

 前稿の末尾で iBeacon の「常時監視・単品管理モデル」に少し触れましたが、これは倉庫等の保管場所にある商品に iBeacon を取り付け、その存否(存在するのか、しないのか)を iPad 等の端末により常時監視するというものです(下図)。本稿ではこのモデルを掘り下げて考えてみます。

天井等、高所に取り付けた端末で商品に取り付けられたビーコンを監視

 

モデルの再定義

本モデルは、iBeacon が取り付けられた商品(以下、ビーコン)が多数存在し、システムでビーコンの存否情報を管理することを目的とします。各ビーコンを監視する端末は1つに定められており、その端末がビーコンの電波を受信しなくなった時点で商品は存在しないものとシステムは認識します。ビーコンは倉庫内を移動することは無い(例えば、上図のA区画から他の区画へ移動することは無い)ものと規定します。このモデルを「定位置ビーコン監視モデル」と呼びます。 これに対して、ビーコンが倉庫内を移動し、移動するビーコンを監視・管理するモデルを「移動ビーコン監視モデル」と呼びます。本稿では、「定位置ビーコン監視モデル」についてのみ扱います。


シナリオ

上図のように定位置にある多数のビーコンを監視するために、必要十分な数のiOS端末(以下、端末、iOS以外の端末に言及する場合はその旨を表記)を配置します。端末にはビーコンの存否(ビーコンの信号検知時には存在、非検知時には存在しないと認識)を監視するシステムをインストールしておきます。端末がビーコンの電波を検知しない場合、データベースのビーコンテーブルのレコードに記録(×で表示)し、ユーザにビーコンが消失したことを通知します。

ビーコンの選択

まず肝心要のビーコンを調達しなければなりません。本モデルでは個々の商品にビーコンを取り付けるので、多数のビーコンを使用することが想定されます。よって、ビーコンの信頼性、保守性、価格、プロダクトライフサイクルが重要になります。また、ビーコンの保守(UUID、Major、Minor、Measured  Power 、出力等の設定・更新)を行うには、多くの場合、ベンダ独自のクラウドサービスを利用することになるので、企業・組織によってはベンダーロックインを懸念し、面倒でも複数ベンダーのビーコン運用を要件とするかも知れません。

ビーコンメーカーとビーコン製品の選択

日本のビーコンベンダーでは、Aplix社アクセス社が有名なようです。Aplix社が料金やマニュアル等の情報を公開しているのに対し、アクセス社はユーザ登録を行わないと詳しい情報が得られないようです。今回は情報がオープンなところを良しとし、Aplix社の製品・MyBeacon® 汎用型 MB004Ac-DR1 (下写真の黒いビーコン)を調達しました。

 一社だけではなく異なるベンダーの製品もチェックすべきと考え、海外のメーカー1社からもビーコンを調達することにしました。海外では Estimote社が有名なので当初はここを第一候補としたのですが、2017年7月に問い合わせたところでは「現行製品には技適マークを取得したものはなく、8月に1製品で技適マークを取得する予定」とのことでした。この世界最大手のビーコンメーカーは米国等他の市場に手一杯で日本市場には手が回らない様子のため、今回はEstimote を見送ることにしました。

 次に候補に挙がったのが Onyx社で、ここは世界第4位のビーコンメーカーとどこかに書いてありました。同社の各製品は技適マークを取得しているところが高ポイントで、営業担当のビアンカさんの応答もとっても早かったです。ということでOnyx社から技適取得の製品 Beacon One (写真の白く小さな円形ビーコン)とEnterprise Beacon (白く大きな円形ビーコン)を3つ調達。2メーカー、3製品の計21個のビーコンでプロトタイプ(後述)によるテストを行うことにしました。

写真左の青いタグ型ビーコンは Gimbal社製 Gimbal Proximity Beacon Series 10
残念ながら今回のテストには間に合わず 

ビーコンの保守・管理

ビーコンの導入時や故障時には、その UUID、Major、Minor 等を設定・変更する必要があります。多くのビーコンベンダーは、ビーコンのクラウドサービスにアクセスさせ、購入したビーコン情報を登録・更新させた後、メーカー独自のビーコンアプリケーションをインストールしたiOS/Android端末をビーコンに近づけて、その端末からビーコンの情報(UUID、Major、Minor、Measued Power、出力等)を登録・更新させます。下図は Aplix社のビーコン管理クラウドサービスの画面で、この画面でビーコンの各種情報を更新します。

【Aplix社のビーコン情報管理用クラウドサービスの画面】
Aplix のビーコン CMS 画面
AplixのサービスはビーコンのCSVデータを取込/書出できる為、多量のビーコンを管理し易い


 Aplix社のケースでは上記で登録した情報に iOS/Android 端末上の MyBeaconTool でアクセスし、同端末をビーコンに近接させた上でビーコン情報の更新を行うことができます。



【iPad 上のAplix MyBeaconToolの画面】
Aplix MyBeaconTool
MyBeaconTool がクラウド上のデータを基にビーコンへの書き込みを行う。

ビーコンの性能・安定性

本モデルに限らずビーコンを使用したシステムでは、当然ながらビーコンが安定して動作することが重要です。下表は小社で開発したビーコン監視システムのプロトタイプ(以下、プロトタイプ、詳細は後述)を使用して、21個のビーコンを約60時間、監視テストした結果です。「Distance」はビーコンと端末の間の距離です。テスト中、ビーコンは移動していないので、本来であれば端末は常にすべてのビーコンを検知した状態でなければなりません。Aplixの10個のビーコンについては、60時間で端末が非検知と認識したのは1個体の1回のみで、高い安定性を示しましたが、Onyxは非検知が多く発生し、各個体で性能にバラつきがありました。
 尚、今回のテストにあたっては、各ビーコンの出力は初期値のまま使用しています。

Result of beacons heart-beats monitoring using iPad and FileMaker Go
Distance
Aplix MB004
Onyx One
Onyx Ent.*1
  M/M*2 Results M/M Results M/M Results
 0.1m 1/6 OK        
1m 0/2 OK        
2m 0/3 OK 39/20112 OK 1/7319 OK
0/4 OK 39/20168 OK    
5m 0/5 OK-1 39/20841 OK 1/7320 NG-288
1/1 OK 39/20862 NG-222    
9m 1/2 OK 39/21289 OK 1/7321 OK-4
1/3 OK 39/21351 OK    
9m  w/obst.*3 1/4 OK 39/21903 NG-14    
1/5 OK 39/21920 OK-1    
Total 10   8   3  
*1 Onyx Beacon Enterprise
*2 Major/Minor
*3 Beacons with obstacles placed nearby are 9 m away from device
*4 OK without number indicates  "Always detected by device"(signal never lost during test), Numbers beside OK/NG indicate the number of times beacons lost.


プロトタイプについて

今回、上表のテスト実施時に使用した FileMaker 16 によるプロトタイプの開発・テスト環境と仕様は以下の通りです。

■開発・運用環境
使用端末 iPad/iOS10.3.3
運用ソフト FileMaker Go 16
開発用ソフト FileMaker Pro Advanced 16
サーバソフト FileMaker Server 16
ベースソフト FMEasy在庫 IWP/WD R1.5」をベースにカスタマイズ
■仕様
UUID関連(下図) ・UUID/Major/Minor(テーブル、以下UMM) は階層構造とする
・UMMテーブルは商品テーブルとは分離する
監視(下図) ・RangeBeacon関数により指定されたUUID(複数指定可)を発信するビーコンを繰り返しスキャン
・設定した閾値を超えてビーコンが連続して非検知の場合、当該ビーコンのレコードに記録する(例えば、閾値を3とした場合、端末が3回連続してビーコンを検知しない場合、レコードに「×」と書き込む)


【UUID管理画面】0
FMEasy在庫の UUID 管理画面カスタマイズ例
上図の[監視]をチェックすると端末の監視対象となる

ビーコンの存否の監視は、天井などに固定されたiPad(端末)で行います。端末が3回連続してビーコンの検知をしないとそのビーコンは存在しないものと認識して、[存否]フィールドに「×」を書き込みます。
注:
閾値を1にして、1度でも非検知が発生したら即刻レコードに「×」を入力することも可能ですが、人、台車、移動中の物品に電波を遮られることを想定し、3に設定しています。

【iPad のビーコン監視画面】
FMEasy在庫のビーコン常時監視カスタマイズ例
監視端末 = iPad の画面。「×」は非検知ビーコン。複数のUUIDを持つビーコンを監視できる。

 

プロトタイプによる事前テストについて

 ビーコン導入のプロジェクト、特に多数のビーコンの導入を伴うようなプロジェクトでは、プロジェクトの初期段階でプロトタイプを用いたテストを実施すべきと思います。プロトタイプによりユーザの要求仕様の実現に目途をつけると共に、ビーコンの総数や、端末がビーコンの信号を安定して受信するためには端末をいくつ用意し、どのように配置するかという計画もこの段階で立てるようにします(じゃないと、概算費用も見積もれませんよね?)。

 上表の監視テストは、当方の事務所内で、なるべく障害物を置かない状態(上表の*3を除く)で、実施しています。ただ、表のテストとは別時間にほぼ同環境で実施したテストでは、端末から9mは離れたAplix社のビーコンが検知されないことがありました。Aplix社のサイトでは、端末がビーコン信号を受信できる距離について、「非常に大まかな目安」として「端末を手に持った状態で50~100m程度、鞄やポケットの中にある場合は30m前後」と述べる一方、「展示会などの人混みの多い場所では低い位置に設置したBeaconが人の列に阻まれ5mの地点でも受信できないケース」もあるとしています。また同サイトは受信の可否について以下が影響を与えるとしています。

    1.Beaconの送信出力、アンテナのゲイン、放射パターン
    2.受信側スマートフォンの感度、アンテナの向き等
    3.スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
    4.周囲環境(建材、人体等)による反射・吸収・回折

 倉庫などでは、多段のラックに商品を配置し、ビーコン信号がラックや他の商品に遮断されてしまうことも考えられます。
 プロトタイプによる事前テストでビーコンと端末の配置計画を作成します。実運用開始後もビーコンの非検知が多発するようであれば、非検知のエリアに端末を増設できるようにシステムを構築し、運用を工夫する(例:端末を増設した場合、その端末に担当させる商品群の Major は別の Major に変更する)ことも重要でしょう。

端末のスキャン速度

 本プロトタイプでは、端末が常時あるいは一定の間隔で対象とするビーコンをスキャンするのですが、その時に使用する FileMaker の関数が RangeBeacons という関数で、この関数にはスキャンするビーコンの UUID(Major/Minorも追加指定可)とタイムアウト(スキャンする時間)を引数として指定します。

 今回のテストでは21個のビーコンに3種類のUUIDを設定しました。RangeBeaconsを実行するには最低限 UUID を指定しなければならないため、21個のビーコンをスキャンするには異なる3つのUUIDを指定し、RangeBeaconsを3回実行する必要があります。また、タイムアウトをあまり短く設定するとスキャン漏れが発生するため、5(秒)に設定しています。つまり、21個のビーコンを1回スキャンするために3回RangeBeaconsを実行するので、それだけで15秒を要することになります。

 端末が担当する全ビーコンの1回あたりのスキャンをできるだけ短くするには、ビーコンの UUID または UUIDとMajorを合わせた値を1つに限定し、1回のビーコンスキャンで実行する RangeBeacons の回数を1回にします。

 【プロトタイプのビーコン監視タブの下部に表示されるスキャン情報】
iBeacon スキャン結果
RangeBeacons3回で15秒だがその他の処理もあるため、実際は22.2秒(平均)を要した。

監視端末と課題

本モデルにおいて、ビーコンと同様またはそれ以上に重要な要素は、監視端末です。ビーコンが安定していても、それを検知する端末が不安定ではシステムは機能しません。

 また、ビーコンを配置するエリアが広いと、端末数も普通は多くなります。野球のグラウンドのような一辺が100メートル、1万平米の倉庫にある商品にビーコンを取り付けるケースで、10m×10mの区画に分けて端末を配置するには100台の端末が、5m×5mの区画に分けて端末を配置するには400台の端末が必要になります。iPad が1台3.5万円、FileMaker Go ライセンスが1万円/年とすると端末1台に必要な初期導入費用は4.5万円、これだけで高額なシステムとなってしまいます。そもそもこのモデルで使用する端末はビーコンを監視し、その結果をデータベースに書き込むという単純なものなので、多数の端末を導入するケースでは、 iPad や FileMaker Go に代わるソルーションが求められます。

端末で考慮すべきこと

ここでは主に端末の価格について書きましたが、多数の端末を管理・運用する場合、小社が端末に求める要件は以下の通りです。
  1. 廉価性 ― 1台、数千円程度
  2. 遠隔操作により本体の起動、再起動、その他の管理ができること
  3. 遠隔操作によりビーコン監視ソフトを起動、再起動、管理できること
  4. 遠隔一括管理 ― 上記2と3の起動、再起動などを遠隔から全端末に対して一斉に実行できること
  5. 高信頼性 ― 24時間/365日稼働すること
  6. 端末の死活(ハートビート)監視 ― 端末故障時にユーザに通知する機能

次回は iPad/FileMaker Go を使用しない端末ソルーションについて考えてみます。


(土屋)

参考サイト
http://business.aplix.co.jp/beacon/beacon_faq.html


IoT/M2M関連リンク

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 関連記事を読む

(土屋)

2013-07-25

簡単? FileMakerで在庫管理(6) ―― 場所別在庫レコードの作成方法

 ブログ記事「簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握する」では、倉庫等の場所別の在庫数算についてご紹介しました。
 今回は、同機能のキモとも言える場所別在庫レコードの作成方法についてユーザ様よりお問い合わせをいただいたので、以下にその概要をご紹介します。

場所別在庫レコードの作成方法

1.場所別在庫テーブルとそのレコードの作成方針


 先の記事で紹介した場所別在庫算出方法では、下図のような場所別在庫テーブルが必要となります。



 ここで必要十分なレコードは、在庫場所テーブルと商品テーブルのデカルト積となります。


例:
在庫場所TBのレコード
A(倉庫)
B(倉庫)
C(倉庫)

商品TBのレコード
X(商品)
Y(商品)
Z(商品)

場所別在庫TBレコード
AX
AY
AZ
BX
BY
BZ
CX
CY
CZ

 さて、場所別在庫テーブルでデカルト積となるようにレコードを生成すると、各倉庫の在庫(=[c場所別在庫数])に漏れはなくなりますが、倉庫に一度も入出庫が発生していない商品がある場合、余分なレコードが存在することになってしまいます。

 たとえば、倉庫Aにおいて商品Xは入出庫したことがあるが、商品Y、Zについては入出庫が一度も発生していない場合、AXレコードは必要ですが、AY、AZレコードは、通常は不要です。
 処理速度が遅くテーブル結合が貧弱な FileMaker では、余分なレコードを極力作成しないように設計すべきでしょう。

 ということで、今回の仕様においては、入出庫登録を行う際に場所別在庫テーブルに当該商品のレコードの登録有無をチェックして、未登録の場合のみ、レコード登録を行うようにします。


2.実装概要


◇リレーションシップ

場所別在庫_入出明細#出庫 (新設、出庫明細TBと場所別在庫TBのリンク用)
場所別在庫_入出明細#入庫 (新設、入庫明細TBと場所別在庫TBのリンク用、下図)
[このリレーションを使用して、このテーブルでのレコード作成を許可]の✔を忘れずに

◇スクリプト

g確定Btn (変更、OnRecordCommitで実行されるスクリプト)
  • 入庫/出庫画面のレコード確定(OnRecordCommit)時に、入出明細ポータルをチェックし、場所別在庫レコードが存在しなければ、同レコードを作成します。
    下図の赤いフィールドは場所別在庫_入出庫明細#入庫::在庫場所IDフィールドですが、これが空欄であるということは、[在庫場所ID]=5(座間倉庫)の当該商品の場所別在庫レコードが存在しないということを意味します。その場合は、[入庫場所ID]の値を[場所別在庫_入出庫明細#入庫::在庫場所ID]に入れ、場所別在庫レコードを作成します。
  • 本スクリプト実行時になんらかのエラーが発生した場合は、エラーが発生した旨のダイアログを表示し、ダイアログ内の“OK”ボタンでレコード確定を中止し、“レコード復帰”ボタンで明細行の作成をキャンセルするようにします。
    場所別在庫レコードの作成に失敗しているにも関わらず入出明細レコードのみ確定されると、その入庫数分の在庫はシステムから消失してしまうので注意が必要です。

3.その他

  • 万が一、関連する場所別在庫レコードがない入出明細レコードが発生した場合に備え、入庫/出庫テーブルに[c在庫場所ErrMsg]フィールドを作成し、エラーが発生した場合にのみ画面に表示する、というのは用心深い良いプラクティスと言えるでしょう。
  • 場所別在庫テーブルは巨大化しやすいので、場所別在庫が0で且つ入出庫が最近発生していない場所別在庫レコードを削除するバッチ処理を検討しておくことが望ましいです。

2013-07-24

簡単? FileMakerで在庫管理(5) ―― 倉庫間移動

 当ブログの在庫関連記事 簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握するでは、「FMEasy在庫 R1.0」をベースに倉庫などの在庫場所別に在庫数を算出する方法について概容を説明しました。

 そんな折、「FMEasy在庫 R1.0(開発版)」のユーザ様から、倉庫間移動に関するご質問を頂戴しましたので、今回はその手法をご紹介します。

商品の倉庫間移動


 まず、下図の青色で囲った部分をご覧ください。



 出庫画面に移動先を入力するための[移動先ID]フィールドを配置しています。
 倉庫間移動が発生する場合、ユーザは移動先のIDを入力した後、“倉庫移動”ボタンをクリックします。すると、出庫画面で入力した出庫明細と同内容のデータが入庫にも作成されるという流れになります。


下準備


 取引先マスタに「倉庫間移動」という管理項目を登録しておきます。
 このとき、倉庫間移動の[取引先ID]は「41」であったと仮定してみます。


倉庫移動スクリプト


 倉庫移動ボタンに割り当てるスクリプト仕様はおおまかに以下のとおりです。
  1. $moveTo 変数に移動先IDをコピー。
  2. 出庫明細(ポータル)内のすべての商品ID/出庫数を $prodArrayに変数配列として格納。
  3. 新規ウインドウで入庫レイアウトを開き、新規レコードを作成。
  4. [入庫場所ID]フィールドには変数1、[仕入先ID]フィールドには「41」を入力。同時に[入庫日]、[担当ID]、[伝票区分]にも適切な値を入力。
  5. $prodArray 変数に格納した出庫明細の要素を、入庫明細の商品ID/入庫数に展開。同時に各[在庫場所ID]には $moveTo 変数に保持されている値を設定。
  6. 入庫レコード確定。

 このスクリプトの実行結果は下図のようになります。



注:
  • 入庫明細作成時、場所別在庫テーブルに座間倉庫用の商品が登録されているかチェックし、無ければ登録する。 ここをミスると、商品がシステム上から消失してしまうので、要注意。
  • 入庫画面の[備考2]に移動元のIDと[場所名](倉庫名)を記録するとわかりやすい。
  • 取引先テーブルに各倉庫名を登録、さらに在庫場所テーブルに[取引先ID]フィールドを新設し、そこに各在庫場所に対応する[取引先ID]値を記録し、[仕入先ID]には上記「41」の代わりに、その倉庫の[取引先ID]を入力するのも良い。
  • 社内倉庫間の移動であるから、[仕入単価]は適切に処理 ― 例えば0を入力― する。
  • 倉庫が隣接しておらず、日単位のタイムラグが発生する場合、“倉庫移動”実行タイミングや[入庫日]の値を考慮すること。

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 のどれが一番有利かは検証が必要です。それについては機会を改めてやりたいとは思っています。



(亀澤)

2012-12-20

簡単? FileMakerで在庫管理(3) ―― 倉庫など場所別に在庫数を把握する

 弊社では在庫管理システムの講習を行っていますが、時折「うちは在庫の保管場所が複数あるので、保管場所毎に在庫を管理したいのだが、おたくの講習は対応できる?」との問い合わせを受けることがあります。 

 実のところ、複数の在庫場所に対応した在庫管理システムの構築は難度が上がってしまうのですが、なんとかコアの部分だけでも本記事でご説明させていただきます。

倉庫など場所別に在庫数を把握する


 ここでは、『FMEasy在庫 R1.0』で複数の在庫場所を管理できるように、仕様変更してみることにします。
 これまでに弊社の在庫管理講習を受講された方、または『FMEasy在庫R1.0(開発版)』ユーザ、倉庫別在庫管理の考え方を学びたい方の参考になれば幸いです。

  1. テーブル設計
    1. 在庫場所テーブル (新設、倉庫/保管場所等管理用マスタ)
      • ID(主キー)
      • 場所名(テキスト)
    2. 場所別在庫TB(新設)
      • ID(主キー)
      • 場所ID(外部キー)
      • 商品ID(外部キー)
      • 導入時在庫数(数値、導入時に元々あった商品在庫数を在庫場所別に記録)
      • 繰越在庫数(数値、繰越処理実行時に特定時点の商品在庫数を在庫場所別に記録)
      • c場所別在庫数(場所別在庫算出用計算フィールド)
      • g在庫基準日1/g在庫基準日2(入出庫の期間特定用グローバルフィールド)
    3. 入庫テーブル/出庫テーブル(変更)
      • 入庫場所ID/出庫場所ID(新設、入出庫場所を登録)
    4. 入出明細TB(変更)
      • 在庫場所ID(新設、入庫テーブル/出庫テーブルの入庫場所ID/出庫場所IDをコピーする)

  2. リレーションシップ設計

  3. レイアウト(LAY)/スクリプト設計
    1. 在庫場所LAY(新設、場所別の在庫数をポータルに表示)
    2. 入庫LAY/出庫LAY(変更)
      • 入庫場所ID/出庫場所IDを配置する
      • OnRecordCommitで入庫場所ID/出庫場所IDを入出明細テーブルの在庫場所IDフィールドにコピー
      • OnRecordCommit時、必要に応じて場所別在庫レコードを作成(4-a参照)

  4. 考慮すべき事項
    1. 場所別在庫レコードを作成するタイミング
    2. 複数倉庫がある等、場所別に在庫を管理しようとすると、FileMakerの場合、どうしても場所別に商品を登録しておく専用テーブル(場所在庫テーブル)が必要になる。そこで、場所別在庫レコードを登録するタイミングが問題となる。余分なレコードをテーブルに極力保持しないためには、入出庫レコード登録時(OnRecordCommit)に、未登録商品の場所別在庫レコードを登録するように制御する。 
    1. 倉庫間移動に対応
      • 出庫時、倉庫1の出庫伝票を、入庫時、倉庫2の入庫伝票を作成
      • 倉庫2の入庫伝票作成漏れを防ぐ
      • 倉庫2の入庫伝票作成後の関連伝票更新をどう考えるか?
    2. 出入庫同時作成機能(商品の近接場所間移動時)
    3. その他


リレーションシップ


 まず、テーブルでキモとなるのが場所別在庫テーブルですね。このテーブルにより、場所別に商品在庫数の算出が可能となります。
 ここで特に重要なフィールドは、在庫場所ID、商品ID、c場所別在庫数(計算フィールド)です。なお、下図で場所名と商品名は商品テーブルと在庫場所テーブルを参照しています。

【場所別在庫テーブルを表形式レイアウトに表示】



在庫算出部分のリレーション。

↓ 


 入出明細テーブルには商品ID/在庫場所ID(出庫元/入庫先の在庫場所ID)と入出庫数が登録されているわけだから、入出明細テーブルと場所別商品在庫テーブル上記のようにリレートして、以下のように計算式フィールをを作ればよいでしょう。 

元々ある在庫+特定期間のSum(入庫数)-特定期間のSum(出庫数)

注:
 「元々ある在庫」は繰越処理が未実行であれば[導入時在庫数]、実行済であれば[繰越在庫数]となり、「特定期間」はユーザが指定する[g在庫基準日1]と、[g在庫基準日1]のOnObjectValidate/Saveで起動するスクリプトにより制御された[g在庫基準日2]の値により決まります。
 [g在庫基準日2]の設定値については、「簡単? FileMakerで在庫管理(2)」の図が参考になると思います。

 他にもリレーションシップの追加はあるのですが、難しくないので省略します。


レイアウトとスクリプト


 入庫/出庫レイアウトには、それぞれのテーブルで新設した[入庫場所ID]と[出庫場所ID](入出庫した場所を示すID)を登録し、OnRecordCommit時に入出庫明細テーブルの[在庫場所ID]にコピーします。
 なお、Commit時に、入出明細テーブルに入力されている[商品ID]で場所別在庫テーブルに未登録の商品は登録するという、第2のキモともいうべきスクリプトについては、できれば機会を改めて書きたいと思います。

【出庫レイアウト】


 最後に在庫場所別に商品在庫数を表示するレイアウト。ユーザが[在庫基準日]に日付入力することにより、その日付時点の各商品の在庫数が表示されます。


【在庫場所レイアウト】

ポータル部分に在庫数(=場所別在庫::c場所別在庫数)と商品テーブルの情報が表示されます。
以上、『FMEasy在庫』というテンプレートをベースにカスタマイズしてみましたが、半日強の時間でとりあえず場所別在庫数は表示できるようになりました。
 上述の場所別在庫のレコード作成処理や、繰越処理は別途作成しなければなりませんが、意外と実装に時間はかかりませんでした。


 (土屋)

2012-06-01

簡単? FileMakerで在庫管理(2) ―― 繰越処理の考え方

 今回は、繰越処理に伴う在庫算出について考えていきましょう。 在庫算出の基本については、以下の記事をご覧ください。

 簡単? FileMakerで在庫管理(1) ―― 在庫算出の基本


繰越処理の考え方


 入出庫のレコードが増えてくると、在庫算出時に合計する入出庫明細レコードが膨大になり、処理速度が低下します。
 そこで、在庫数の繰越処理を行うことによって、在庫算出処理を行うことにより、在庫数算出を高速化する必要があります。
 
 たとえば、商品Aの2011年6月~2012年5月の入出庫明細データが10万件あったとします。
 2012年5月31日時点の商品Aの在庫を算出しようとして、入出庫明細レコードを10万件を対象に、Sum(入庫明細::入庫数)-Sum(出庫明細::出庫数) をやっていては、処理時間が膨大になってしまいますが、繰越処理を実行することによって2012年4月末時点の商品Aの在庫数を商品テーブルに保管しておき、5月1日~5/31の入出庫明細レコードのみをSumの対象となるようにリレーションを組めば、Sumの対象となるデータは、単純試算では10分の1以下となります。

 次に在庫算出の計算式を、以下のように繰越処理を行った場合と、行ってない場合とでは、在庫算出の計算式が違ってきます。

A式: 導入時在庫数+(4/25以前の入庫計)-(4/25以前の出庫計)

B式: 繰越処理日≦在庫基準日の場合の在庫算出式
繰越在庫数+(4/1~4/25の入庫計)-(4/1~4/25の出庫計)


C式: 繰越処理日<在庫基準日の場合の在庫算出式
  導入時在庫数+(2/28以前の入庫計)-(2/28以前の出庫計)

 要はA、B、Cの式をCase分けして、ひとつにまとめる必要があるわけです。



繰越処理と制御


 さて、繰越処理で考えておかなければいけない重要なことが一つあります。それは、繰越処理日(上記例では3/31)以前のデータ、在庫に関していえば、3/31以前の入出庫レコードの出庫日と入庫日、出庫数と入庫数を変更不可にしておく必要があります。また、3/31以前の同レコードは削除させてはならないし、繰越処理日以前の入出庫日を持つ同レコードは作成させてもいけません。 

 その理由は、[繰越在庫数]との整合性がなくなってしまうからです。

やがて訪れるデータ削除の時期について:
 長期間使用するシステムでは、繰越処理を行ってもレコードはどんどん蓄積されていきます。当社が開発・保守を担うシステムでは百数十万件の入出明細データを持つテーブルがありますが、ほぼ定期的にデータ削除を行っています。小社では、FileMaker のテーブルの最大レコード蓄積数は200~300百万件を一つの目安としていますが、データの削除は、システム仕様、実行速度要求、保持データ数要求、バックアップポリシー等の諸事情を勘案し、システムが安定動作することを大前提に実行してください。一般ユーザがデータ削除を行う場合は、一括データ削除機能も必要になります。
 また、削除したデータを照会したい、といった要望も必ずといっていいほどユーザより提示されるので、できれば過去データの照会についても予め考慮してシステム設計を行います。


在庫管理は簡単か?


 残念ながら答えは NO です
 システム的には、繰越処理とそれに伴う伝票制御、旧データ削除時の処理を考慮せざるを得ず、在庫管理システムを作るのはやはり簡単ではない、というのが結論になります。

 また、繰越処理関連を適正に実装できたとしても、1カ月に同一商品の取引が数百回以上あるような業務では在庫算出処理の遅延も予想され、別の在庫算出手法(拙稿の「FileMaker V10による在庫管理、一考」の123を参照)の採用も選択肢に入れなければならないでしょう。



土屋

2012-05-27

簡単? FileMakerで在庫管理(1) ―― 在庫算出の基本

 本稿は2012年5月に投稿されたものです。2018年2月現在、最新の FileMaker のバージョンは 16 となっていますが、本稿及び続稿で記述した在庫に関するの設計手法は現在も有効と思われます。
 ただ、iBeacon/EddyStone の登場等や、記事に気になる点があったため、今回、加筆修正することにしました。また、SQLを使った在庫の繰越処理などについても加筆したいと思っているのですが、これについては別の機会にしたいと思います。
(土屋企画)

 本稿では FileMaker を使用した在庫算出の方法について考えます。ただ本論に入る前に、在庫算出の3つの手法を大雑把に見てみます。それぞれの手法に便宜的に名前を付けていますが、これらは筆者が勝手に名付けたもので、社会、業界で一般的に利用されている名称ではありませんので、他所で「入出庫小計差分法を採用したいのですが…」とか言っても、相手の方は「???」となるでしょう。

在庫算出3つの手法

入出庫小計差分法

  この手法は当方の様々な在庫管理システムで使用している方法で、FileMaker で在庫算出する際の一般的な手法と思われます。いつの時点の在庫を知りたいのか(以下[在庫基準日])を決め、その時点までの入庫数計と出庫数計を計算、その差分が在庫となります。下図の4/30時点の在庫は、4/30迄の入庫計=20と出庫計=6の差分で[在庫]=14となります。
 Excelでは、出庫数の横に在庫列を作成して「D4+B5-C5」などとすれば簡単に在庫が求められますが、リレーショナルデータベースではそうした計算はできません。なぜならリレーションの無い行同士の演算はできないからです。無理に外部キーを振ったり、スクリプトのループで加減演算しても、結局は破綻します。
この方法は比較的単純ですが、特定の商品が頻繁に取引されるようなシステムでは、在庫算出処理に想定外の時間を要する可能性があります。

在庫マスタ逐次書換法

本手法は下図のように入出庫に変動があった場合、在庫マスタの[在庫]フィールドを即時更新する、というものです。下図を例に説明すると、3/31に[入庫数]=10を入力してコミットすると、在庫マスタテーブルの商品Aの[在庫]は即刻10に更新され、4/1に[出庫数]=1を入力すると[在庫]は9に即更新されます。
この方法は、入出庫伝票更新時に在庫マスタを即更新するため、その後発生する在庫照会や在庫表印刷の処理では各商品の在庫算出を行うことはなく、高速です。ただ、実装方法が難しいこと、上述の在庫基準日を指定できないこと、入庫日と出庫日には未来の日付を入力できないことなど、デメリットは少なからずあります。 ただ、同一商品の入出庫が頻繁に発生し、リアルタイムに在庫を把握する必要がある業態では、この手法を採用することが多いでしょう。実は2009年に本手法に関する投稿とサンプルファイル(現在リンク切れ)を公開しています。興味があるかたはこちらをどうぞ。

ビーコン信号カウント法

近年リリースされた iBeacon/EddyStone(以下、ビーコン) は少ない電力(電池)でユニークな値(UUID/UID)を含む信号を数カ月~数年、0m~100mほどの範囲で発信する装置です。
土屋企画で使用するビーコン ― 左の小さいタグ型ビーコンは 40mm×28mm 
このビーコンを製品に取り付け、その信号を取得・処理することでほぼリアルタイムに商品の在庫を把握することができます。以下のシステム図は 、Raspberry Pi と呼ばれる超小型Linux機(価格は約3000円/台)を広い倉庫内に万遍なく配置、ビーコン信号を漏れなく取得し、データベースの在庫テーブルを更新するというものです。
 入出庫システムからは独立して、在庫数の把握が可能となります。

本手法はビーコンが高価(500円~数千円~)であること、取り付けが不能・不向きな製品があること、電池に寿命があり交換が必要なこと等、ビーコン特有の問題があります。ビーコンについてはこちらを参照してください。


在庫算出の基本

さて、それでは上述の「入出庫小計差分法」について以下そのしくみを見ていきます。

 「2012年6月20日時点の在庫」というような特定時点(在庫基準日)の在庫数を算出するために、以下のようなTOG(テーブル・オカレンス・グループ)を作成してみます。


 商品マスタと出庫明細と入庫明細をリレートするだけですのでシンプルですね。
実際アプリケーションでは、出庫明細や入庫明細を格納するための出庫と入庫のテーブルが必要ですが、ここでは省略します。
 以下は上記リレーション |×| で示された部分のリレーション編集イメージです。


 [g在庫基準日]は日付のグローバルフィールドという特殊なフィールドで、詳しくは FileMaker のマニュアルを参照してください。ユーザはこのフィールドで在庫算出の起点となる日付 ― 在庫基準日 を指定します。

 そして、こちらが在庫算出用フィールド=[c在庫数]の計算式です。

繰越在庫数- Sum(出庫明細_商品::数量) + Sum(入庫明細_商品::数量)


 システム導入時、[繰越在庫数]には各商品の導入時点での在庫数を入力します。導入時、在庫が無い商品については「0」を入力しておきます。
 上記の計算式もシンプルで、[繰越在庫数](=ここでは導入時点の在庫数)から[g在庫基準日]以前に出庫した商品数量を差し引いて、さらに[g在庫基準日]以前に入庫した商品数量を加え、在庫を算出しているだけです。
 [g在庫基準日]より後の日付の入出庫が[c在庫数]の計算式の対象とならないのは、上図「在庫算出TOG」のリレーションで「≧」によりそのように定義されているからです。
注:
  1. 本稿読者で「出庫明細/入庫明細テーブルに[出庫日]/[入庫日]があるのはおかしいではないか。  本来、この二つのフィールドは出庫ヘッダ/入庫ヘッダテーブルにあるべきで、冗長で正規化されていないではないか?」と考えた方 、 御尤もです。ただ、FileMaker 内蔵DBを使用し、在庫算出基準日を任意に指定可という仕様を前提にした場合、正規化を崩しても明細に日付を持たせるのが良い、というのが小社の知見です。
  2. 上記1の通りに設計する場合、出庫ヘッダ/入庫ヘッダの[出庫日]/[入庫日]と、出庫明細/入庫明細テーブルの[出庫日]/[入庫日]は常に一致するようにシステム的に保証しなければなりません。ユーザがヘッダ部の[出庫日]/[入庫日]を変更することは頻繁にあるので、スクリプトトリガを使用して、うまく制御してください。

 上記の注2 の部分が少し面倒ですが、ここまでは比較的簡単にアプリを作成できると思います。

 ただ、入出庫レコードが数千、数万と増えるに従い、在庫(c在庫数)の表示には時間がかかるようになります。在庫算出処理の時間を短くするためには、繰越処理を行い、[c在庫数]の計算対象となる入出庫レコードを減らす必要があります。 繰越処理とそれに伴う処理については、 簡単? FileMakerで在庫管理(2)―― 繰越処理の考え方 をご覧ください。

TOG(テーブル・オカレンス・グループ) とは?

FileMaker Pro 7 以降に導入されたリレーションシップグラフでは、テーブルを別名、または同一名で定義して配置できます。
 たとえば「商品」というテーブルは、リレーションシップグラフ上では「商品Table1」、「商品テーブル」、「商品」など自由に名前をつけて配置したり、同一のテーブルを別名で複数配置したりできます。

 リレーションシップシップウィンドウに配置されたテーブルは、単に”テーブル”と呼ばれたり、テーブルのエイリアスあるいはTO(テーブル・オカレンス)と呼ばれることもあります。

 FileMaker界隈 では TO という呼び名が一般的になってきているようです。また、処理別やレイアウト別に TO をグループ化したものを TOG (テーブル・オカレンス・グループ)と呼んでいます。


 以下の動画では『FMEasy在庫 IWP/WD 1.5』という製品を使用し、在庫算出に関して説明しています。




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

(土屋)

2009-12-25

FileMaker V10による在庫管理、一考 その3

前回作成した在庫アプリ(ZaikoTestV0.fp7)の課題メモ

0.在庫と商品のテーブル分離
複数ユーザによる同時アクセス競合をできるだけ回避するため、在庫と商品のテーブルは分離し、在庫以外の商品情報はもっぱら商品テーブルに持たせる。 在庫テーブルは在庫データ専用とする。

1.競合発生時の処理
1-1 書き込みループ 
ZaikoTestV0.fp7では在庫更新時に競合エラーが発生すると、最終保存時点までRevert(ロールバック)してしまうので、競合するユーザの在庫書き込み処理が終了し、自身の在庫書き込みが成功するまで、書き込みをループさせる(最大ループ数有)。

1-2 遅延オプション
FileMaker Server 10 Advanced を使用すると、スペック的には999ユーザまでが同時アクセス可能となる。 つまり、最大999ユーザが特定の商品の在庫数を同時更新する可能性がある。
人気の新商品のリリース時に膨大な数の受注が想定される場合は、逐次処理を行うのではなく、一定間隔で明細レコードを集計して、在庫を更新するようなオプションを考慮する。 もちろん、在庫の算出は、“一定間隔”の分、遅延する。

2.在庫算出時点
特定の日付を指定して、その日付時点の在庫数を算出する場合は、「商品別末日時点在庫テーブル」を作成して月次処理を行い、この際に各商品の末日時点の在庫数をこのテーブルに書き込む。
これにより、日付指定により在庫を算出する場合でも、クエリの対象となるデータを最大1~2カ月程度に限定できる(高速化)。

以上


【関連リンク】


2012/8/1追記:
当社の在庫管理の講習で使用してるサンプルシステム「FMEasy在庫」を公開しました。フリー版/開発版のダウンロードは→こちら

【FMEasy在庫 の画面】