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-11-08

SQL Server 2000 を FileMaker 11で使う

 FileMakerが公式サポートしているMicrosoft SQL Server のバージョンはMS SQL Server 2008 R2/MS SQL Server 2008 SP2/MS SQL Server 2005 SP3のみです。

 が、10年程前に SQL Server 2000 と ASP で作成したシステムのデータをちょこちょこ弄る必要がでてきました。
 これを Active Server Page でやるのは大変すぎるので、FileMaker Pro 11でSQL-Server 2000のDBを扱えないものかと無謀にも思い立ち、試してみました。

 本記事は、その備忘録となります。

 例によって「システムDSN」を登録。
 環境は Windows 32bit、ODBCドライバは「SQL Server 6.00」。
 問題なく登録できる。



 次に FileMaker Pro 11 Advanced を起動してFileMakerデータベースを作成。
 上記で登録したDSNをFileMakerの外部データソースとして登録する。



 さらに、リレーションシップのウインドウで、上記で登録した SQL Server データベースのテーブルをTO(Table Occurrence)として現出させ、リレーションとかもしてみる。問題なし。



 FileMaker では TO 毎にレイアウト(フォーム)が自動作成される。ブラウズモードにして、表示方法を「表形式」を選択すると、以下のような表が表示される。



 ここまで、慣れていれば5分程度で作成できる。
 いまのところ、照会/検索は普通にできている。



 最後に躓いた点のメモ:

 上記のFileMakerデータベースを Windows Server 2008 x64 の FileMaker Server で運用する場合、普通にDSN登録をすると、上記のリレーションシップのところでエラーが起こると思われる。
 この場合、SysWoW64フォルダの odbcad32.exeを起動して、DSN登録を行うこと。

参考リンク


(土屋)


【IWP関連記事】

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


2012-07-18

QNAP障害発生時のマイグレーション

今回発生したQNAPの障害を機に、ハードディスクではなく、QNAP本体で障害が発生した場合のマイグレーション(Migration)をシミュレートしてみた。 ここでいうマイグレーションとは、障害が発生した元QNAPのハードディスクを新QNAPに移動し以後QNAP2で運用することを言う。
以下、今回行ったシミュレーションの手順・注意点を記録しておく。

1.障害はハードディスクかQNAP本体かを見分ける
ハードディスクの障害であればマイグレートしてもしかたがない、というか余計症状が悪化する可能性もある。ハードディスク障害の症状、チェック方法、復旧方法については、以下を参照。

QNAPで恐怖のエラーがぁぁぁぁああああ

本体のHDDのLEDが赤く点滅していればHDD障害の可能性大。LEDが緑(点滅)であっても、PCからアクセスできない、ブラウザからQNAP管理画面の左ペインの(いくつかの)リンクにアクセスしようとすると「Loading Driver Please Wait... 」と表示されたままになりアクセス不能、RAID情報を見ると理由もないのに「Sychronizing...」していてHDDのLEDが緑点滅している、という状況があればHDDが疑わしい。

今回のようにHDDが中途半端に生きている場合、「Sychronizing...」(十数時間)→アクセス障害→手動再起動→アクセス復旧→「Sychronizing...」(十数時間)→アクセス障害→手動再起動… をHDDが完全に死んでLEDが赤点灯するまで何十時間も繰り返すことがあるので、障害原因がハードディスクかQNAP本体かをいかに早く見極めるかが、腕の見せ所。



3.事前確認
今回のシミュレーションでは、「元QNAP(いままで運用中のQNAP)本体が障害を起こしたと仮定し、元QNAPの4台のHDDを新しいQNAPに移し(マイグレーション)、ネットワーク上のマシンから問題なくアクセスできることを確認、その後4つのHDDを元QNAPに戻して運用を再開する」という一連の作業を行う。 かなり不安な作業なので、QNAPサポートにこれを実行して問題ないかを問い合わせたところ、「問題ない筈だが、マイグレーションに関する以下のURLを読んでみろ」とのこと。

曰く、「After the migration has finished, all the settings and data will be kept and applied to the new NAS. However, the system settings of the source NAS cannot be imported to the destination NAS via “System Administration” > “Backup/Restore Settings”. Configure the NAS again if the settings were lost.」
つまり、元QNAPの設定とデータは新しいQNAPに継承される。が、“System Administration” > “Backup/Restore Settings”を利用しても、元の設定を取り込めないこともあるので、その時は手動で設定してね、と怖いことが書いてある。 元QNAPで行った設定はすべてスクリーンショットを取っておき、万が一の場合は手動設定する準備をしておく必要がある。


4.元QNAPのファームウェアのアップグレード
実際にQNAP本体に障害発生した場合、ファームのアップグレードはできないが、今回はシミュレーションなので、マイグレーション前に元QNAP機のファームをアップグレードした。 

まず、アップグレード前にファームの更新履歴をみて、アップグレードの可否の判断を行う。 QNAPファームは頻繁にアップグレードされバグも多いようなので、この判断は慎重に行うこと。 今回は3.5.0→3.7.1へとアップグレードを行った。

アップグレードに要した時間は10分程度だったか。終了後は再起動を求めてきたので再起動。 ところが、再起動後にまた「Synchironizing...」が始まった。 これに要した時間が10時間強。QNAPのサポートにこの件を問い合わせたが、「通常、Synchironizeはそうそう起こるものではない。今回の原因はわからない」とのことだった。


5.マイグレーション、そして再度元のQNAPへ戻す
10時間強のSynchronizeが終わったところで、元QNAPの電源を落とし4台のHDDを抜き取り、新QNAPに移して電源をいれた。 数分で問題なく起動してきた。これでマイグレーション作業は終了。
ところがログをチェックしてみると、「The firmware versions of the system built-in flash (3.4.2 Build 0331T) and the hard drive (3.4.2 Build 20120615) are not consistent. It is recommended to update the firmware again for higher system stability.」と出ている。ファームウェアは、ハードディスクと本体フラッシュメモリの両方にあるらしい。マイグレーション先の新QNAPのフラッシュ内のファームが古いというのは当然だが、元QNAP内にあった4台のハードディスクのファームが3.4.2というのはおかしい。


一方、“Firmware Update”のリンク をクリックすると、「Current firmware version: 3.7.1 Build 20120615」と表示される。 よってthe hard drive (3.4.2 Build 20120615) の表記はバグと思われる。

今回はシミュレーションなので新QNAPでのファームのアップグレードは見送り、この状態でブラウザのQNAP管理画面からチェックをおこなった。IPアドレス、その他は旧QNAPの設定がそのまま継承され、マシン名も旧QNAPと同様である。その他の設定も旧設定をそのまま継承している。ここで、旧QNAPを使用していた仮想/物理マシンを起動してみたが、問題なくアクセスできた。

一通りチェックが終わったところで、新QNAPの電源を落とし、4つのハードディスクを新QNAPから取り出し、元QNAPに戻した。 されに元QNAPの電源を入れてログをチェック。 問題がないことを確認後、各マシンから再びアクセスをさせたところ、問題なく動作した。

(土屋)