ラベル スクリプトトリガ の投稿を表示しています。 すべての投稿を表示
ラベル スクリプトトリガ の投稿を表示しています。 すべての投稿を表示

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在庫 の画面】

By 時刻: 0 件のコメント:
ラベル: , ,

2009-12-24

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

前回作成した在庫アプリは新規出庫しか在庫と連動していなかったので、出庫伝票の更新/削除時も在庫が変更するように、修正してみた。　どんなものか見てみたい方は下記からどーぞ（パスワードはかかってませんよ）




【関連リンク】

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

【FMEasy在庫 の画面】

By 時刻: 0 件のコメント:
ラベル: , ,

2009-12-11

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

久々のFileMaker(以下、FM)の話題。
V9以前のFMでは、在庫を算出する場合は、在庫テーブルで以下のようにやっていたのではないだろうか？

在庫：：在庫(計算) = 在庫：：前月分在庫 - Sum(出庫明細：：出庫数) + Sum(入庫明細：：入庫数)


このやり方は簡単でいいのだけれど、出庫明細や入庫明細のレコード数が多いと、1つの商品の在庫の算出にさえ、数十秒から数分の時間がかかってしまう可能性がある。　よって、商品数と伝票枚数（商品取引）が多く、リアルタイムの在庫を即時把握したいような業種では、FMは使えなかった。
言い換えると、在庫や各種残高算等、あるテーブル(上例では、出庫明細、入庫明細)のフィールド値に基づき計算を行いその結果を他テーブルの（計算フィールドではない）フィールドに精度を確保しながら保存する、ということができないということは、1995年のV3リリース以来、FMの長年の弱点の一つであった。

そんなところにFM V10が現れたのは一年程前だったか。　このバージョンでFMはイベント発生時のスクリプト起動（以下、スクリプトトリガ）に対応した。　スクリプトトリガ、特に、レコード保存時にスクリプトを実行する「OnRecordCommit」により、上記の弱点が解消される可能性がでてきたように思われる。
以下、その原案。

1.　想定（目標）
以下のような簡単な在庫管理データベースがあり、出庫伝票作成時に各商品の出庫数を在庫数から差し引くことを目的とし、その実装（スクリプト）を考えてみる。
尚、出庫伝票は新規作成のみであり、明細の更新は不可（ホンナ無茶な）とする。

【図1】


【図2】

図1の出庫伝票で、［出庫数］に入力をしレコードを保存する動作を行った時に、在庫リストの［在庫数］の値が［出庫数］を差し引いた値に更新されればいい。　但し、このとき在庫リストの［在庫数］は計算ではなく、数値フィールドである、というのが今回の肝である。


2.実装
まずレコードを保存（Commit）時に在庫テーブルの［在庫数］フィールドから［出庫数］を差し引くスクリプトが必要である。

【図3】


という具合に、出庫明細を1行づつ移動して、関連する在庫レコードの［在庫数］から［出庫数］を差し引き、［在庫数］にセットする。　途中あるエラー処理は、［出庫数］更新時にエラーが発生した場合、このスクリプトで行ったすべての処理を取り消し、レコードを最後に保存した状態に戻すためのものである。

では、ユーザの操作（クリック）に依存せず、レコード保存（Commit）時に必ずこのスクリプトを実行するにはどうしたらよいか？　ここでＦＭ V10の新機能、スクリプトトリガの「OnRecordCommit」を使用する。　詳細はマニュアルを見ていただくとして、下図のように上記で作成したスクリプトを登録すればよい。

【図4】

以上で完了。


3.テスト
テストをしてみると、一応、機能する。
図1の出庫伝票入力後に保存を行うと、商品1~3の［在庫数］は正しく「9」に更新される。

また、［在庫数］更新時にエラーが発生すると、その出庫伝票が最後に更新されたときの状態に戻り、在庫レコードも元の状態に戻る。
たとえば、商品1と2の［在庫数］の更新には成功したが、商品3の［在庫数］の更新に失敗すると、すべての処理が取り消され、最後の保存状態に戻る。　このとき、出庫レコード自体が一度も保存されていなければ、明細レコードだけではなく、出庫レコードも保存されない（作成されない）筈である。　


4.課題
さて、上記のように当初の思惑は達成されたが、いくつかの課題と懸念がある。
  1. 今回は出庫伝票は新規のみである、ことを前提としているが、当然、これでは実用には耐ええない。出庫明細の更新、削除にも対応する必要がある。
  2. 在庫テーブルで極力競合が発生しないようにテーブル設計する必要がある。
  3. 十分なテスト --- マルチユーザで競合が発生しないこと、また競合発生時も整合性が確保されること。
  4. 上記実装が正しく機能しているか、検証する仕組みの構築

1.は面倒だか、明細の主キー、商品ID、更新前の［出庫数］と更新後の［出庫数］の差分を変数に記憶しておき、Commit時に個々の商品の［在庫数］からその差分を減算すれば、解決可能である。

クリティカルな環境で上記のような在庫ロジックを実装し、実際の運用まで持ち込むのはなかなか大変だと思われるが、在庫や残高の算出遅延が運用上のネックとなっているシステムでは、一考の価値があるのではなかろうかと。

以上

土屋


【関連リンク】

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

【FMEasy在庫 の画面】


By 時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)